4

After reading this awesome explanation of how SSL works, I now have a confusion.

The answer states that the first messages of SSL are ClientHello and ServerHello(in response to ClientHello). Both of which are unencrypted, correct me if I am wrong. Also the client does not start sending encrypted until ChangeCipherSpec is issued.

So both ClientHello and ServerHello contain the "client random" and "server random" and also the session-id. Now AFAIK the data is encrypted using a symmetric encryption key, that is, the client and server both have a copy of the same key and encryption/decryption is done via that single key for that SSL session.

And isn't that key suppose to be computed using the "client random" and "server random" ?

So if the ClientHello and ServerHello are both plaintext can't the attacker just use the same algorithm as the client and generate his own symmetric key and converse with the server impersonating the client ?

How is this not possible ? What am I missing here ?

UPDATE: The phases of ServerKeyExchange and ClientKeyExchange also happen before ChangeCipherSpec so they are also suppose to be unencrypted.

3

You are missing the coolest part. Diffie Hellman Key Exchange: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

This part is the bit that allows the keys to be generated at each end by swapping details in the clear. Even if an attacker intercepts the clear communications they cannot themselves recreate the output. Very clever as the algorithm is known to everyone and by knowing that offers the attacker no advantage.

Also worth noting that if a man in the middle attacker intercepts and actively changes anything within the protocol while it is not encrypted when the protocol conducts the message authentication stage it would notice it had been tampered with and fail.

2

So many of the improvements in TLS hinge on the Finished message: as soon as ChangeCipherSpec, a Finished message is sent encrypted with the new negotiated parameters. Both server and client have to immediately decrypt this message, which contains hashes of the handshake thus far. If there's a mismatch, say from a man-in-the-middle attack, it will be detected here.

If you didn't do this, you can get attacks similar to the ones you are wondering about. See my answer on that here for more details.

0

The Diffie-Hellman key exchange algorithm allows two parties to stipulate a shared secret known to both of them, but not knowable to anyone observing the communication. At no point is there any operation authenticating either party. That is why the server sends the certificate to the client, because it contains the server's public key and is signed by a trusted third party (the CA), thus authenticating the server to the client.

Now the client can generate a key to use for symmetric encryption and send it encrypted with the server's public key to the server trusting that only the entity who has been issued the SSL certificate can decrypt it and use it to communicate with the client. In order to prevent a MitM attack as you describe, the client would also have to be authenticated to the server using a client certificate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.