I'm creating an application with Python to simulate a WebRTC client a/v connection. I'm at the stage where i need to generate the local client's SDP to send to the remote server. I've done some searches on the internet and most of the results points to using java script. Is there a way to do this on Python without Java scripting?
You might want to give aiortc a try, it is a Python WebRTC implementation.
On a windows client, I have a service ticket for a web service (I can see the ticket with klist), and I am trying to write an
app to get the encoded service ticket and pass it on to the service (over HTTPS) so that it can be decrypted with the service key.
By using the klist example provide in the windows SDK (at \Microsoft SDKs\Windows\v7.0\Samples\security\authorization\klist) I am able to get a handle to the service ticket and get a KERB_EXTERNAL_TICKET structure that contains the
"EncodedTicket" which claims to be "A buffer that contains the Abstract Syntax Notation One (ASN.1)-encoded ticket."
Is this "EncodedTicket" the ticket that I want to pass onto my webserivce? Will it still be encrypted with the service key? How do I convert this buffer into a base64 string that I can pass on to my webservice?
I wrote a tool which transfer data over https channel to server. Now it need to be verified what data I transferred is exactly right or not by testing team.
Is there any tool which will capture the data transferred by program over https. I am transferring data in xml format which in not encrypted.
I tried this with Fiddler but its unable to trace the data.
Any tool which you know?
If you have the server's private key and are not using Ephemeral Diffie-Hellman cipher suites (those with EDH or DHE in their names depending on the configuration used), you should be able to look inside the SSL/TLS traffic using Wireshark and its SSL mode.
If you don't have the server's private key, you can try using a MITM proxy (in which case you will need to make your client trust its certificates), possibly one of these:
http://mitmproxy.org/
http://crypto.stanford.edu/ssl-mitm/
http://www.charlesproxy.com/documentation/proxying/ssl-proxying/
I want to implement a Client-Server program in which the client has to send a file to the server. In this case, what is the efficient way to send the file to server?
I am thinking in the following method,
After the connection establishment, First, I have to send the file name (which i want to upload) to server from client. Then I have to send the file content to server. The server will wait for the file content after received the file name from client.
So, for uploading a file, I need 2 write method in client & 2 read method in server.
Is this ok? Is there any other efficient way for doing this?
I think that your idea is correct. Maybe you should consider not to send files name (only the extension line .jpg) and let server generate one. This will prevent overwriting some already existing files.
I want to know how HTTPS is implemented. Whether the data is encrypted or path is encrypted (through which data is passed). I will be thankful if someone provides me implementation details.
Very simply, HTTPS uses Secure Socket Layer to encrypt data that is transferred between client and server. SSL uses the RSA algorithm https://en.wikipedia.org/wiki/RSA_(cryptosystem), an asymmetric encryption technology. The precise details of how the algorithm works is complex, but basically it leverages the fact that whilst multiplying two large prime numbers together is easy, factoring the result back into the constituent primes is very, very hard. How all SSL/RSA encryption works is:
The server generates two large prime numbers, and multiplies them together. This is called the "public key". This key is made available to any client which wishes to transmit data securely to the server. The client uses this "public key" to encrypt data it wishes to send. Now because this is an asymmetric algorithm, the public key cannot be used to decrypt the transmitted data, only encrypt it. In order to decrypt, you need the original prime numbers, and only the server has these (the "private key"). On receiving the encrypted data, the server uses its private key to decrypt the transmission.
In the case of you browsing the web, your browser gives the server its public key. The server uses this key to encrypt data to be sent to your browser, which then uses its private key to decrypt.
So yes all data transmitted to/from server over HTTPs is encrypted - and encrypted well. Typical SSL implementations use 128 or 256 digits for their keys. To break this you need a truly vast amount of computing resources.
As far as I am aware the request for a server asset is not encrypted - use httpfox https://addons.mozilla.org/en-US/firefox/addon/6647/ or Wireshark http://www.wireshark.org/ or something to confirm.
In two ways.
By ensuring that all information transmitted between you and the website is encrypted. It does this via a key-exchange process using RSA (which exchanges a 'session key', which is used for the actual encryption).
By (trying to) demonstrate trust in the website you visit. Certificates are provided to domains, and the idea is that on your machine you trust only certificates from various reputable sources. Then, you can (in theory) be assured that when a certificate pops up for "Your Bank", it is really "Your Bank" website, and not some other website. In practice, very few people care/notice this aspect of SSL.
It's transport layer security. It is not application level. You still need to follow secure coding practices and various other techniques to ensure that your site is secure.
I thought this was a really concise human readable explanation:
http://robertheaton.com/2014/03/27/how-does-https-actually-work/
Here is my summarised version:
Concepts:
Asymmetric cryptography algorithm – Public key encryption, private
key decryption.
Symmetric cryptography algorithm – Public key
encryption and decryption.
Handshake:
Hello – Client send cryptography algorithm and the SSL version it supports.
Certificate Exchange – Server sends certificate to identify itself, and certificate public key.
Key Exchange – The client uses Certificate public key to encrypt a new client regenerated public key (using the agreed asymmetric cryptography algorithm from step 1) and sends it to the server. The server decrypts it using its private key (using asymmetric cryptography algorithm).
Data Exchange - This public key is now know by both client and server. It is used for subsequent requests/responses for both encryption and decryption on both client and server (symmetric cryptography algorithm)
You can read all the details in the TLSv1 RFC-2246.
For security analysis, specifically the following section:
F. Security analysis
The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel.
This appendix outlines how TLS has been designed to resist a variety
of attacks.
further content snipped
Server and client do not have control over the path that is used to transmit the data. The path used is a matter for the network layer (Internet Protocol - IP), not for the Transport Layer Security (TLS)
The data itself is encrypted, and there are also means for checking server autenticity, as mentioned by Noon Silk.
http://en.wikipedia.org/wiki/Transport_Layer_Security