In process of SSL handshake, several message like ServerHello, ClientHello, ServerKeyExchange messages are exchange before the actual encryption starts.

  • Are these messages encrypted?
  • If not then can a bad guy make illicit use of it? If yes, then how?

I am wondering if these messages are not encrypted then bad guy can take for example take session id from ServerHello, or key exchange from ServerKeyExchange message and make illicit use of it.

I know that after "Change Cipher Spec Message" communication is encrypted but what happens to the SSL handshake communication before that.

2 Answers 2


As stated in RFC 5246:

The TLS Handshake Protocol involves the following steps:

  • Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.

  • Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret.

  • Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.

  • Generate a master secret from the premaster secret and exchanged random values.

  • Provide security parameters to the record layer.

  • Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.

To answer your questions:

  1. a. ServerHello and ClientHello aren't encrypted. (No critical information.)

b. ServerKeyExchange is not encrypted. (No critical information)(To understand how a key exchange without an encryption works, see DHKE)

  1. There is a verification to detected an attacker.
  • Thank you for inputs. "ServerKeyExchange is encrypted." How it can possibly be encrypted because when ServerKeyExchange message is sent by server then pre-master secret is not yet exchange, so there is no encryption. What I am wondering is bad guy can take the key from ServerKeyExchange and impersonate to be the client. How this situation is handled. Aug 22, 2015 at 23:52
  • The key exchange phase includes a part of the pre-master secret.
    – tintin
    Aug 23, 2015 at 0:04
  • There is a public (the one send) and a private part, with these two both sides calculate a the pre-master secret. Impersonation is always possible, the attack is called man-in-the-middle. The scenario would be an intended secure communication between alice and bob, but eve sits in the middle and an answers to all request with his credentials. So we have eve as a proxy between them, relaying all messages. The attack is probably detected by one of the parties, because of the certificate chain in the browser.
    – tintin
    Aug 23, 2015 at 0:17
  • 1
    @hagrawal while it may not seem possible if you haven't run into the concept before, there is such a thing as perfect forward secrecy, which allows two hosts to agree on a shared secret without actually exchanging that secret.
    – Nic Barker
    Aug 23, 2015 at 2:16

ServerHello and ClientHello? - nope they're in the clear.

Key exchange? The premaster secret is encrypted using the public key from the certificate so only the authenticated server can read the premaster secret. Or in the case of Diffie-Hellman the key exchange is signed by the server and verified by the client using the server certificate public key.

Therefore an attacker without the private key cannot either decrypt or sign the key exchange.

  • Thank you for your inputs. "Or in the case of Diffie-Hellman the key exchange is signed by the public key." Whose public key? I am talking about ServerKeyExchange, which is sent from server. I would agree that ClientKeyExchange is encrypted (not signed) using server's public key present in the certificate. Aug 23, 2015 at 18:47
  • Thank you for your inputs. I referred msdn.microsoft.com/fr-fr/library/cc783349%28v=ws.10%29.aspx to understand the concept but here there was no mention that key sent in ServerKeyExchange is signed by server's private key. Are you sure about it? Could you please provide me some reliable reference where I can read about it? Aug 23, 2015 at 19:59
  • 1
    In the link it says With EDH key exchange, the pre-master secret is the result of the EDH operation. In this case the ephemeral DH key is signed by the server’s private key. Aug 23, 2015 at 20:14
  • Ohh ok, thanks. I got this line in context client key exchange because of this line above it - The client must transmit the Pre-Master Secret securely to the server. but then I should have thought that how client can sign from the server's private key. Aug 23, 2015 at 20:20
  • And please don't mind, it had already marked other answer as accepted and don't wish to take it back because it could be discouraging for a starter. He did a fairly good try. Aug 23, 2015 at 20:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .