I keep reading that Symmetric session key is used in SSL after handshake only for faster performance but isn't true a secondary session key either Symmetric or Asymmetric key generated by the client during run-time is needed to make the communication secure.

Isn't it because the network traffic can be decrypted that is generated by the server using the private key which can be encrypted by any client which has a public key as long as they can sniff the traffic like the man-in-the-middle if no session key exists ? Can someone please clarify ?

  • Please read the RFC of the TLS protocol and indicate precisely which keys you are referring to. You first need to clarify the question before we can even think of clarifying TLS. – Maarten Bodewes Sep 17 '15 at 16:43
  • I am talking about the symmetric encryption session keys in SSL/TLS that gets generated from the client after the initial SSL handshake is done. – user1370642 Sep 17 '15 at 16:59
  • There is no such thing. The session key is generated via a key agreement protocol, not by the client. The phrase 'secondary session key either symmetric or asymmetric generated by the client' also refers to nothing in the real world. Your second paragraph is basically meaningless. Unclear what you're asking. – user207421 Mar 20 '17 at 19:09

I'm having trouble understanding exactly what you are asking but I'll take a whack...

As you point out, the private/public key pair that is associated with the server can be used for encrypting data sent to the server because only the server has the private key to decrypt. But there is no secure way for the server to send data to the client. All the client has is the server's public key which, as its name suggests, is public. So encrypting data with the private key and sending to a client is readable by everyone. So, without a symmetric key, there's no way to encrypt data being sent to the client.

Note that a different encryption model than SSL could have the client generating a public/private key pair for every SSL handshake. The server would then use the client's public key to encrypt data sent to it. The reason this isn't done is, as you stated, asymmetric encryption is slow (and less robust in other ways) so this is a bad choice.

Also, because a unique key is used for the transfer of data, you can establish forward secrecy. Forward secrecy assures that even if the private key gets discovered at a future date, it is still impossible to decrypt a recording of the communication.


Forward secrecy?

I have trouble understanding the question.

But I think you're talking about TLS Key Exchange. Namely the difference between RSA Key Exchange and DHE Key Exchange/ECDHE Key Exchange.

The DHE/ECDHE key exchanges are forward secrecy enabled. The RSA key exchange is not. (When you can: prefer ECDHE/DHE.)

  • For DHE/ECDHE another additional/secondary layer of public-key-crypto is used to do the key exchange. And the public/private-key-pairs are then thrown away.

  • While the RSA Key Exchange reuses the existing public/private-key-pair that is already used in the TLS certificate.

Further reading

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.