https--using Wireshark to observe the SSL/TLS handshake process-bidirectional authentication/one-way authentication

The SSL/TLS handshake process can be divided into two types:

1) SSL/TLS two-way authentication, that is, both sides will be mutual authentication, that is, the exchange of certificates between the two.
2) SSL/TLS one-way authentication, the client authenticates the server side, and the server does not authenticate the client identity.

We know that the handshake process is actually the process by which the two parties negotiate to exchange a key for symmetric encryption, and the handshake process is clear.
This process actually produces three random numbers: Client random, Server random, Pre-master secret. Refer to the graphical SSL/TLS protocol.

The first two random numbers are transmitted in plaintext, and only pre-master secret is encrypted (RSA or DH).
In general, the signature algorithm can choose RSA or DSA algorithm when generating the certificate.
If the server uses an RSA certificate, RSA can be used as a signature or as an asymmetric encryption, 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 flowchart (from rfc5246), the steps in parentheses are optional.
In the case of one-way authentication, the blue font portion is not required.
4 Server_key_exchange This step is only required if certain key exchange algorithms such as the DH algorithm are selected.

Client	Server
1 Client Hello
	2 Server Hello 3 Certificate 4 (Server_key_exchange) 5 (Certificate_request) 6 Server_hello_done
7 (certificate) 8 Client_key_exchange 9 (certifiate_verify) Ten Change_cypher_spec ----finished----
	Change_cypher_spec ----finished----

The following uses the Wireshark to crawl the handshake process message. Server/client uses Java7/jsse encoding. Server certificate signing algorithm rsa-two-way authentication

Visible includes all steps except 4. Because the RSA algorithm is taken, step 4 is not required.

(a) First, the client provides the following information to the server

Client_hello
(1) Supported protocol versions, such as TLS 1.0
(2) supported cryptographic algorithms (Cipher Specs)
(3) The random number generated by the client is 1 (challenge), which is later used to generate the "conversation key".

(ii) the server answers the following information to the client

Server_hello
(1) Confirm the protocol version used
(2) server generated random number 2, later used to generate "conversation key"
(3) Session ID
(4) Confirm the encryption algorithm used
Certificate
Server certificate
Server_key_exchange
If it is the DH algorithm, the DH parameter that the server uses is sent here. The RSA algorithm does not require this step.
Certificate_request
Require the client to provide a certificate, including
(1) The type of certificate the client can provide
(2) The server accepts the certificate Distinguished Name list, which can be either the root CA or the subordinate CA. If the server is configured with trust KeyStore, the distinguished name of all certificates in trust KeyStore is listed here.
Server_hello_done
Server Hello End

(iii) client sends to server

Certificate
Client certificate
Client_key_exchange
Contains Pre-master secret. The client generates a third random number. If the RSA algorithm is used, it generates a 48-byte random number, which is then encrypted with the public key of the server and then placed in the message, if it is the DH algorithm, the client's DH parameter is sent, and then the server and the client calculate the same pre-master according to the DH algorithm. Secret
certificate_verify
Send all handshake message signature results received and sent using the client certificate to this step.
Change_cipher_spec
The client notifies the server to begin sending messages using encryption. The client uses the above 3 random number client random, Server random, Pre-master secret, calculates the 48-byte master secret, which is the key of the symmetric cryptographic algorithm.
finished
The client sends the first encrypted message. The HMAC algorithm is used to calculate the digest of all handshake messages received and sent, and then the results are computed by a pseudo-function PRF defined in RFC5246 and sent after encryption.

(iv) Server sent to client
Server-side sends Change_cipher_spec and finished messages. Shake hands to the end here.
Server Certificate signing algorithm dsa-two-way authentication

The following is a server certificate using the DSA algorithm for the handshake process. Because the DH algorithm is used to exchange the key, more server_key_exchange this step.

Server certificate signing algorithm rsa-one-way authentication

Compared with the two-way authentication, the server side is less certificate_request, the client side has less certificate and certificate_verify.