2
$\begingroup$

I would like to understand better what happens during establishment of SSL/TLS secure connection.

  1. The Client wants to establish a connection - ClientHello
  2. The server answers wit a ServerHello. This includes a randomly generated number and a server certificate
  3. The client creates a "pre master secret" and sends it encrypted to the server using its public key.
  4. Both parties create a session key from random number and pre master secret.

The question:

Is this the same as Diffie-Hellman key agreement? During DH key agreement both parties send a random key to the partner from which the session key is finally generated. DH is (in principle) completely symmetric. Why is the random number from the client called "pre-master-secret" and from the server just "random number"?

$\endgroup$
2
$\begingroup$

No, this is not the same thing as Diffie-Hellman key agreement.

What happens here is that the server authenticates itself by being able to RSA decrypt the pre-master-secret. If the server is able to do that it is possible to perform (H)MAC operations using the derived session key.

A problem with this scheme is that the encrypted pre-master secret can be stored by the attacker - together with the rest of the TLS session. The attacker can then try and find the private key value. Once that is found all the data of that particular session and all other sessions protected with the private key can be decrypted.

DHE_ and ECDHE_ ciphersuites work differently. The key pairs are generated on the fly; i.e. the key pairs are ephemeral (the E in DHE). Both client and server establish a session key. The server (or the client and server) then authenticate by performing signature-generation (for authentication). This has the advantage that each session needs to be attacked separately. This is known as (perfect) forward secrecy.


The server's random is a value that does not need to be protected. It is used as derivation data for generating the master_secret from the pre_master_secret. If it wasn't present then the key would not be dependent on a random source of the server. This is a problem if the client's random number generator is not secure (enough). The pre-master secret on the other hand needs to be kept secret.

Note that the server cannot send an encrypted value to the client as the client is not authenticated at that time.

$\endgroup$
1
$\begingroup$

Already answered at https://security.stackexchange.com/questions/63971/how-is-the-premaster-secret-used-in-tls-generated:

"The client generates the 48-byte premaster secret by concatenating the protocol version (2 bytes) and some bytes that the client generates randomly (46 bytes)."

$\endgroup$

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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