SSL interaction (handshake) process details

Original article: http://www.cpplive.com/html/1387.html

CommonTCPCommunication cannot ensure data security. It may be intercepted by a third party at any time and the privacy of the two parties is leaked. This is obviously not what we want to see, especially with the user name,PasswordCommunication processes that are closely related to personal information (such as online banking transactions, transmission of confidential files, etc.) are especially important to the confidentiality of data interaction, so we often useSSLThe SSL protocol ensures that the data of the Interaction parties is transmitted in ciphertext mode, and the third party cannot crack the data without the private key, thus achieving the purpose of confidentiality. Many people do not know how SSL interacts with data to ensure security. To answer your questions, we will introduce the SSL interaction process in detail here.

1. Establish a TCP connection

Because the SSL protocol depends on the implementation of TCP connections, a TCP connection must be established before SSL interaction.ClientConnectServerThe acccept client on the server. After three handshakes, the TCP connection is established.

2. The client sends an SSL request

The client sends the SSL used by the client to the server.Version(SSL has three versions ),EncryptionAlgorithmConfiguration, random data, and information required for the SSL protocol.

3. The server processes SSL requests.

The server sends feedback to the client about its SSL version and encryption.AlgorithmConfiguration, random data, and privateKeyEncrypted server-Hello information. The server then passes its certificate (including the public key) over. There is also an optional item, that is, the server can ask the client to send its own certificate.
4. The client verifies the server identity

The client uses the server to pass the certificate to verify the identity of the server. If the identity is not verified, the communication ends. After the certificate is verified, the public key of the server is used to unbind the server-Hello Information encrypted with the private key. If the decryption fails, the server-Hello information must be false, therefore, the communication is terminated.

5. The client sends random data encrypted with a public key.

The client generates random data (sharedsecret) and encrypts the random data with the public key sent by the server, this encryption process generates the premastersecret in this handshake (this step may involve the participation of the server, which is determined by the encryption algorithm they use), and then premastersecret) return to the server ). If the server needs to verify the client, the client also needs to pass its own certificate (including the public key, at the same time, send some self-signed (private key encryption) data to the past.

6. The server uses a private key to decrypt the encrypted random data and negotiate the secret number.

After the server authenticates the client, it uses its own private key to decrypt and obtain the premastersecret. Then, both parties use this premastersecret for joint negotiation to obtain the mastersecret (which can be understood as the premastersecret as the secret number negotiated by both parties, then, use this secret to negotiate a mastersecret to generate a real session key for data transmission.) This ensures the security of data resolution.

7. The server and client generate the encryption algorithm and key using the hidden signs.

Both parties use mastersecret to generate a real sessionkey, which is a symmetric encryption key. This key can also be used to verify data integrity. Both parties exchange end information. The handshake ends.

next, both parties can use the negotiated algorithm and key, the symmetric encryption algorithm is used for communication.