SSL handshake process [closed]

问题:

I am getting started on security and read about the SSL handshaking scenario. In this post, the replier mentioned that the symmetric key is generated on the browser, encrypted using the server's public key and sent over to the server.

However, in the other articles, they mentioned that a pre-master secret was generated and sent over instead for calculation of the symmetric key.

May I know which is the correct explanation, and how is this pre-master secret generated and used to generate the symmetric key?

回答1:

The description in the post you linked to is just a simplified explanation of the protocol.

The client generates the pre-master secret, and encrypts it with the server's public key as part of the handshake process. Both sides then derive the symmetric key material, including IV's and MAC key's, according to the method in RFC 6101.

回答2:

Below is a link to an excellent article describing the SSL/TLS handshake (including the use of the pre-master secret by both the client and server to generate a master secret, which is used to generate a set of session keys for MAC and encryption):

The First Few Milliseconds of an HTTPS Connection

回答3:

Saying that the browser generates the symmetric key is just a simplification (at least better than saying the encryption is done with the certificate). You may be interested in this answer on Security.SE for more details:

The cipher suite then determines how these symmetric keys are eventually shared. The immediate purpose of the SSL/TLS handshake is to establish a share pre-master secret between the client and the server. This is more broadly referred to as the key-exchange (see RFC 4346 Appendix F.1.1, and perhaps Section 7.4.7).

This falls in two categories (excluding anonymous key exchange):

• RSA key exchange (e.g. TLS_RSA_WITH_AES_128_CBC_SHA): the client encrypts the pre-master secret using the server's public key (found in the certificate).
• DH(E) key exchange (e.g. TLS_DHE_RSA_WITH_AES_256_CBC_SHA): a Diffie-Hellman key exchange takes place. The server signs its DH parameters and the client verifies the signature against the public key in the server certificate. (Having an RSA-based certificate doesn't imply an RSA key exchange.)

At the end of the handshake, whichever of these two steps were used, the client and the server are in possession of a common pre-master secret, from which they derive a master secret (see RFC 4346 Section 8.1).

From that master secret, both parties can derive the encryption keys (and MAC secrets), as described in RFC 4346 Section 6.3.