The SSL/TLS handshake process can be divided into two types:
1) SSL/TLS mutual authentication means that both parties will authenticate each other, that is, certificates will be exchanged between the two.
2) SSL/TLS one-way authentication, the client will authenticate the identity of the server, and the server will not verify the identity of the client.
We know that the handshake process is actually a process in which the two communicating parties negotiate and exchange a key for symmetric encryption, and the handshake process is in plain text.
This process actually generates three random numbers: client random, server random, and pre-master secret. Refer to the illustration of the SSL/TLS protocol . The
first two random numbers are transmitted in plain text, and only the pre-master secret is encrypted (RSA or DH).
Generally, when generating a certificate, the signature algorithm can be RSA or DSA algorithm.
If the server uses an RSA certificate, RSA can be used as a signature or asymmetric encryption. The pre-master secret is encrypted with the public key contained in the server's RSA certificate.
If the server uses a DSA certificate, DSA can only be used as a signature, so you also need to use the DH algorithm to exchange keys.
The following is its flow chart (taken from rfc5246 ), the steps in parentheses are optional.
If it is a one-way authentication, the blue font part is not needed.
4 The server_key_exchange step is only needed when certain key exchange algorithms such as DH algorithms are selected.
| Client |
Server |
| 1 Client Hello | |
| 2 Server Hello |
|
| 7 (certificate) 8 client_key_exchange 9 (certifiate_verify) 10 change_cypher_spec ----finished---- |
|
| 11 change_cypher_spec ----finished---- |
Next, use wireshark to capture the messages of the handshake process. The server/client uses JAVA7/JSSE encoding .
Server certificate signature algorithm RSA-two-way authentication
It can be seen that all steps except 4 are included. Because the RSA algorithm is adopted, step 4 is unnecessary.
(1) First, the client provides the server with the following information
client_hello
(1) Supported protocol version, such as TLS 1.0
(2) Encryption algorithm (Cipher Specs) supported by the
client (3) Random number 1 (Challenge) generated by the client, slightly It is then used to generate the "session key".
(2) The server replies to the client with the following information
server_hello
(1) Confirm the protocol version used
(2) The random number 2 generated by the server, which will be used to generate the "session key" later
(3) session id
(4) Confirm the use encryption algorithm
certificate
server certificate
server_key_exchange
If the DH algorithm, DH parameters used by the server to send here. The RSA algorithm does not require this step.
certificate_request
requires the client to provide a certificate, including
(1) the type of certificate that the client can provide
(2) a list of distinguished names of certificates accepted by the server, which can be root CA or subordinate CA. If the server is configured with a trust keystore, the distinguished names of all certificates in the trust keystore will be listed here.
server_hello_done
server hello ends
(3) The client sends to the server
certificate The
client certificate
client_key_exchange
contains the pre-master secret. The client generates the third random number. If the RSA algorithm is used, a 48-byte random number will be generated, then encrypted with the server’s public key and then put into the message; if it is the DH algorithm, the DH parameters of the client are sent here, and then the server and the client are based on DH algorithm, each calculates the same pre-master secret.
certificate_verify
sends the signing result of using the client certificate to all the handshake messages received and sent up to this step.
The change_cipher_spec
client informs the server to start sending packets in encrypted mode. The client uses the above three random numbers client random, server random, and pre-master secret to calculate the 48-byte master secret, which is the key of the symmetric encryption algorithm.
The finished
client sends the first encrypted message. Use the HMAC algorithm to calculate the digest of all handshake messages received and sent, and thencalculate the resultthrough a pseudo-function PRF defined in RFC5246, and send it after encryption.
(4) The server sends to the client The
server sends change_cipher_spec and finished messages. Here is the end of the handshake.
Server certificate signature algorithm DSA-two-way authentication
The following is a handshake process of a server certificate using the DSA algorithm. Because the DH algorithm is used to exchange keys, the server_key_exchange step is added.
Server certificate signature algorithm RSA-one-way authentication
Compared with two-way authentication, the server side has less certificate_request , and the client side has less certificate and certificate_verify .
Reprinted at: https://blog.51cto.com/1192748/1583245