I'm trying to understand how internals of HTTPS works.
I understand that the server uses symmetric encryption using the pre-master key generated by the client and encrypted with the server's public key. My understanding is also that the server encrypts the hashes of resources rather than the actual resources, which the client will then decrypt and verify the hash. But I have two questions -
Is it correct to assume that the actual file is still sent by the server in plain text and that the browser trusts the contents only because it was able to hash the file and verify it with symmetric encryption?
How exactly is the information from the client, such as POST payload or URL parameters encrypted when sent to the server? Would the browser still hash the payload or the URL parameters or will it simply encrypt the data?
Thank you very much in advance for the help!
I understand that the server uses symmetric encryption using the pre-master key generated by the client and encrypted with the server's public key.
Only in some cipher suites. In general you should just regard the session key as securely negotiated by a key-agreement protocol and leave it at that.
My understanding is also that the server encrypts the hashes of resources rather than the actual resources, which the client will then decrypt and verify the hash.
I don't know what this means. The server has to return actual data, not just hashes. There are hashes used over the handshake and the SSL data messages, but that's no concern of yours: it is just part of the privacy SSL provides.
But I have two questions -
Is it correct to assume that the actual file is still sent by the server in plain text
No, of course not, it is encrypted with the session key. That's what the session key is for.
and that the browser trusts the contents only because it was able to hash the file and verify it with symmetric encryption?
No. Forget about hashing. Data is encrypted.
How exactly is the information from the client, such as POST payload or URL parameters encrypted when sent to the server?
With the session key.
Would the browser still hash the payload or the URL parameters
No. Forget about hashing.
or will it simply encrypt the data?
Yes.
Related
We are using AES encryption to encrypt and decrypt data that is sent between browser and the server. AES encryption needs a secret key,which is hard coded and known by the client and the server.
Apart from the shared secret key, AES encryption also needs an initialisation vector( IV), which is unique and generated every time when a new request is sent either from the client or the server.
Is it ok for sharing this uniquely generated vector in every request in the http header between browser and server ? Are there any security risks in doing so?
Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party
I was looking into SSL and some of the steps that are involved to set up an encrypted connection between a server and a client computer.
I understand that a server key and certificate is sent to the browser, and that a secret code is being calculated, like they say in the following video:
http://www.youtube.com/watch?v=iQsKdtjwtYI
around 5:22, they talk about a master secret code that is being calculated to start talking in an encrypted way.
My question now is: before the connection is actually encrypted (the handshake phase), all communication between the server and the client can be sniffed by a packet sniffer. Isn't it then possible to sniff the encryption key or other data that is used to set up a secure connection?
From the Wikipedia summary, I think the key part you're interested in is:
The client responds with a ClientKeyExchange message, which may
contain a PreMasterSecret, public key, or nothing. (Again, this
depends on the selected cipher.) This PreMasterSecret is encrypted
using the public key of the server certificate.
This is why the public key is so important. If you use the wrong public key, you're vulnerable to man in middle attacks.
Witness the justified worry whenever bogus SSL certificate issues (e.g. DigiNotar).
The secret key itself isn't transmitted at all, so it can't be sniffed. It is computed independently at both ends. The materials it is computed from is called a PreMasterSecret which is encrypted with the public key of the server certificate. So unless the server's private key has been compromised the secret key can be neither sniffed nor calculated independently.
If one way SSL is used (Server Certificate authentication) then data sent from client gets encrypted using Public key of the server certificate. So privacy protection is available for data sent from client. My questions are
Does this mean that in One way SSL data sent from Server to client is not encrypted and sent as plain text ?
For both server to client and client to server communications the data/message is not signed and so tamper protection or data integrity is not assured. Are there any other means to achieve data integrity while using SSL based transport security and not Message security options ?
One way SSL just means that the server does not validate the identity of the client. It has no effect on any of the other security properties of SSL.
While the SSL protocol is a bit complex, the basic gist of what happens is this: The client generates a random key, encrypts it so that only the server can decrypt it, and sends it to the server. The server and client now have a shared secret that can be used to encrypt and validate the communications in both directions.
The server has no idea of the client's identity, but otherwise, the encryption and message validation is two way.
Update:
1) Yes, encryption both ways is symmetric and uses a shared secret generated during session setup.
2) With a shared secret, message integrity is trivial to assure. You just ensure the message has a particular form. For example, I can prefix every message I send with a sequence number and append a checksum onto it before encryption. You decrypt it with the shared secret and validate the sequence number and checksum. How can an attacker substitute or modify the message without knowing the shared secret and still keep the sequence number and checksum intact?
In SSL, two things happen:
First, a session key is negotiated using something like the
Diffie-Hellman method. That generates a shared session key but never
transmits the key between parties.
Second, that session key is used in a normal symmetric encryption for
the duration of the connection.
SSL does use public/private in one way, because an X509 certificate is
used to identify at least one end of the connection. Those certs are
signed using an asymmetric key pair.
Extracted from How can SSL secure a two-way communication with only one key-pair?
I would like to read the information a java application in firefox is sending to a website over an ssl connection.
I am using WireShark, and I believe that if I can somehow tell tell wireshark what encryption key firefox is using, then wireshark will be able to decrypt the ssl messages.
Then I will exactly what information this website is getting about my computer.
My apologies if the question is vague ... any pointers on where to start looking for clues would be appreciated.
Not really programming related.
However in order to do this you'll need the certificate for the site your application is connecting to, both the public and the private key parts - so if it's not a site you own then you'd not going to be able to do it. If you control the receiving web site then simply follow the instructions on the wireshark wiki.
Assuming that you're not trying to do this programmatically, but instead just want to view headers whilst debugging, you could use Charles:
http://www.charlesproxy.com/
There's a fair bit of information here about how to set it up to decrypt SSL traffic:
http://www.charlesproxy.com/documentation/using-charles/ssl-proxying/
The java application would encrypt all information with the server's public (SSL) certificate (at least as far as you are concerned). For all practical purposes the only way to decrypt this afterwards is to know the server's private key which you apparently do not have and therefore there is no way that you can decrypt it.
To answer your comment about whether to use your computer's private key:
If this is a "normal" SSL connection, the client (java app) will contact the server and receive its public key, verify it's valid (signed by a trusted CA) and then use it to negotiate a symmetric key that is used for encryption.
Public/Private keys work in a way that everything encrypted by one key can only be decrypted by the other - i.e. everything the Java app encrypts using the server's public key, can only be decrypted using the private key - which never leaves the server.
SSL/TLS supports client certificates, in which the Java app can have its own key pair and use its private key to sign the contents in order to verify the authenticity of itself. However even if the Java app does that (doubtful) it does not help as the data will still be encrypted so that only the server can decrypt it.
Background reading: http://en.wikipedia.org/wiki/Transport_Layer_Security and http://en.wikipedia.org/wiki/Public-key_cryptography