HTTP is based on TCP, and TCP requires three handshakes to establish a connection, while HTTPS requires seven handshakes to establish a connection. The HTTPS seven-way handshake is actually a three-way handshake for TCP connections and a four-way handshake for SSL/TLS connections, which are based on TCP connections. TCP connection establishment is familiar. This section describes the TLS connection establishment process.

1. TLS establishment process

  • 1.1.1 Client –> Server: random number Client key, TLS version, encryption component list, compression algorithm
  • 1.2.1 Server –> Client: random number Server key, TLS version, Server selected (supported) encryption component
  • 1.2.2 Server –> Client: Certificate
  • 1.2.3 Server –> Client: Client Certificate Request, optional. If you need to verify the Client Certificate, this step is required. Otherwise, the message is not sent.
  • 1.2.4 Server –> Client: Server Hello Done
  • 1.3.1 Client –> Server: pre-master Secret
  • 1.3.2 Client –> Server: Change Cipher Spec: prompts the Server to use the pre-master secret key to encrypt subsequent packets
  • 1.3.3 Client —-> Server: The Client Certificate is optional. If the Client Certificate Request message is received from the Server, the message is not returned.
  • 1.3.4 Client –> Server: Finish. The packet contains the overall checksum value of all packets connected so far
  • 1.4.1 Server –> Client: Change Cipher Spec: prompts the Client to use the pre-master secret key to encrypt subsequent packets
  • 1.4.2 Server –> Client: Finish. The packet contains the overall verification of all packets connected so far

Four interactions, each of which may send multiple messages to the other party

1.1 First Flight (Client – > Server)

1.1.1 ClientHello Message The client sends the CLIENT key, TLS version, encryption component list, and compression algorithm to the server. TLS version: Indicates the TLS protocol version supported by the client. The server selects one of the TLS protocol versions and informs the client in the next interaction. Encryption component: Informs the server of the encryption components supported by the client. The server selects one of them and informs the client in the next interaction. Compression algorithm: Informs the server of the compression algorithm supported by the client. The server selects one of the compression algorithms and informs the client in the next interaction.

1.2 Second Flight (Server — > Client)

1.2.1 ServerHello Message Send random number Server key, TLS version, encryption component selected by the server, compression algorithm selected by the server Server Key: Computing factor TLS version for subsequent symmetric encryption: The server selects the protocol version from the TLS version list supported by the client. Generally, the server preferentially selects the version with higher security. If the server selects an encryption component from the list of encryption components supported by the client, it preferentially selects the component compression algorithm with higher security: Compression algorithm selected from the list of compression algorithms supported by the client 1.2.2 Server Certificate Sending the Server Certificate After receiving the Certificate, the client verifies the validity of the Certificate to confirm the identity of the Server. 1.2.3 CertificateRequest Message Sending a Client Certificate Authentication Request (Optional) If the server needs to authenticate the client, send this request for the client to send the client certificate to the server. 1.2.4 ServerHelloDone Message Tells the client that the sent content is complete

1.3 Third Flight (Client – > Server)

Before sending a message, the client verifies the server certificate in 1.2.2. After the verification succeeds, the client sends the following message. 1.3.1 Client Certificate (Optional) Sending a Client Certificate If you have received a Certificate Message in 1.2.4, 1.3.2 ClientKeyExchange Message Send the third key pre-master Secret, A random number encrypted with the public key of the server certificate 1.3.3 ChangeCipherSpec Message Indicates that the negotiated encryption methods and keys are used for future communication. 1.3.4 Finished Message Indicates that the client ends the handshake with a symmetric key. This packet is also an authentication message, which is the hash value of all the previously sent content for the server to verify.

1.4 Fourth Flight (Server – > Client)

1.4.1 ChangeCipherSpec Message Indicates that the client uses the negotiated encryption method and key to encrypt future communications. 1.4.2 Finished Message Indicates that the server ends the handshake and encrypts data with a symmetric key. This message is also an authentication message, which is the hash value of all the previously sent content for the client to verify.

2. Encrypt messages

2.1 Implementation of symmetric encryption

The encryption factors of symmetric encryption are coordinated through three interactions, as follows: [plaintext] ClientKey in ClientHello Message [plaintext] Server Key in ServerHello Message [RSA] Pre-master in ClientKeyExchange Message Secret: the client uses the public key contained in the server certificate to encrypt the message when it is sent. After receiving the message, the server uses the private key to decrypt the message. Master Secret is generated by client key, server key and pre-master Secret. Used to encrypt subsequent communication.

Traffic Analysis of an SSL/TLS Session Symmetric encryption algorithm and TLS