SSL handshake process

I. SSL handshake has three purposes:
1. The client and server need to agree on a set of algorithms used to protect data;
2. They need to establish a set of encryption keys used by those algorithms;
3. Handshakes can also be used to authenticate the client.

Ii. SSL handshake process:
1. The client sends the list of algorithms it supports and a random number used to generate the key to the server;
2. the server selects an encryption algorithm from the algorithm list and sends it to the client with a certificate containing the server public key. The certificate also contains the server ID for authentication, the server also provides a random number used to generate the key;
3. the client verifies the server certificate (for verification certificates, refer to digital signatures) and extracts the server's public key. Then, a random password string called pre_master_secret is generated, use the public key of the server to encrypt it (refer to asymmetric encryption/Decryption) and send the encrypted information to the server;
4. The client and server independently calculate the encryption and MAC keys based on the pre_master_secret and the random numbers of the client and server (refer to DH Key Exchange Algorithm ).
5. The client sends the MAC values of all handshake messages to the server;
6. the server sends the MAC values of all handshake messages to the client.

Steps 5th and 6th are used to prevent handshakes from being tampered. Imagine an algorithm used by an attacker to control the client and server. It is common for clients to provide multiple algorithms. Some of them are weak and some are strong, so that they can communicate with servers that only support weak algorithms. Attackers can delete all the high-intensity algorithms provided by the client in step 1, forcing the server to select a weak-intensity algorithm. The MAC exchange between Step 1 and Step 2 can prevent this attack, because the client MAC is calculated based on the original message, the MAC of the server is calculated based on the message modified by the attacker. After checking, the server will find that the message does not match. Because the random numbers provided by the client and server are input in the key generation process, handshaking is not affected by replay attacks. These messages are the first messages encrypted under the new encryption algorithm and key.

Each step described above must be implemented through one or more handshake messages. First, briefly describe which messages correspond to which steps, and then describe the content of each message in detail. Describes each message:

Step 2 corresponds to a single handshake message, ClientHello.
Step 1 corresponds to a series of SSL handshake messages. The first message sent by the server is ServerHello, which contains the algorithm it selected and then sends its Certificate in the Certificate message. Finally, the server sends the ServerHelloDone message to indicate the completion of the handshake phase. ServerHelloDone is required because some more complex handshaking variants also need to send other messages after Certifacate. When the client receives a ServerHelloDone message, it will know that there will be no other similar messages, so it can continue the handshake.
Step 2 corresponds to the ClientKeyExchange message.
Steps 5th and 6th correspond to the Finished message. This message is the first message that is protected by an algorithm that has just been negotiated. To prevent handshakes from being tampered with, the message content is the MAC value of all handshakes in the previous phase. However, the Finished message is protected by a negotiated algorithm, so we also need to calculate the MAC value of the message from the new negotiated MAc key.
Note that two ChangeCipherSpec messages are omitted.

Iii. SSL record protocol:
In SSL, the actual data transmission is implemented using the SSL record protocol. The SSL record Protocol divides data streams into a series of fragments and transmits them. Each segment is protected and transmitted separately. At the receiver, each record is separately decrypted and verified. This scheme allows the data to be transmitted from one end of the connection to the other end as soon as it is ready and processed immediately upon receipt.
Before transmitting a clip, you must prevent it from being attacked. Data integrity can be guaranteed by MAC computing. The MAC address is transmitted along with the clip and is verified by the receiver. Append the MAC to the end of the clip and encrypt the content that is integrated with the MAC to form the encrypted Payload ). Finally, load the header information. The link between header information and encrypted load is called record. record is actually transmitted. Describes the transmission process:

3.1 record header message:
The record header information is required to explain the records for the receiving implementation. In practice, it refers to three types of information: content type, length, and SSL version. The length field allows the receiver to know how many bytes it takes from the line to process the message. The version number is only a check to ensure that each party uses the negotiated version redundancy. The content type field indicates the message type.

3.2 SSL record type:
SSL supports four content types: application_data, alert, handshake, and change_cipher_spec.
All data sent and received using SSL software is sent in the application_data type. The other three content types are used to manage communications, such as handshaking and error reporting.
Content type alert is mainly used to report various types of errors. Most alert (alerts) are used to report issues in handshakes, but there are also some indications for errors that occur when attempting to decrypt or authenticate records, alert messages are used to indicate that the connection will be closed.
The content type handshake is used to hold a handshake message. Even the handshake message that initially formed the connection is carried by the record layer with handshake type records. Because the encryption key is not yet established, these initial messages are not encrypted or authenticated, but other processes are the same. It is possible to initialize a new handshake on an existing connection. In this case, the new handshake record is encrypted and authenticated just like other data.
Change_cipher_spec indicates that the encryption and authentication changes are recorded. Once the handshake has agreed on a new set of keys, send change_cipher_spec to indicate that the new key will be enabled at the moment.

4. Message collaboration:
As we can see, SSL is a layered protocol that consists of a record layer and a same message type accepted on the record layer. The record layer is carried by a reliable transmission protocol such as TCP. Describes the Co-operation structure:

5. Complete SSL connection process:

Extracted from SSL and TLS