Principle of SSL protocol

Principle of SSL protocol

SSL (Security Socket Layer) is a security protocol that provides a secure connection for TCP-based application layer protocols. SSL is between the fourth and seventh layers of the TCP/IP protocol stack. SSL can provide security cases for the HTTP protocol. SSL provides security guarantee for data transmission on the network.

SSL protocol structure

The SSL protocol structure is divided into two layers:

• The bottom layer is the SSL record protocol (SSL record protocol)

  • Mainly responsible for block, compression, calculation of upper layer data, add MAC (Message Authenticate Code, hash algorithm to calculate message authentication code), encryption, and finally transmit the record block to the other party

• Upper layer: SSL handshake protocol (SSLhandshake protocol), SSL change cipher spec protocol (SSL change cipher spec protocol), SSL alert protocol (SSL alert protocol)

  • SSL handshake protocol: The client and server establish a session through the handshake protocol. The session contains a set of parameters, including the session ID, the other party's certificate, a list of encryption algorithms (including key exchange algorithms, data encryption algorithms, and MAC algorithms), compression algorithms, and master keys. SSL sessions can be shared by multiple connections to reduce session negotiation overhead.
  • SSL password change protocol: The client and server notify the receiver through the password change protocol, and subsequent messages will be protected and transmitted using the newly negotiated encryption algorithm list and key.
  • SSL warning protocol: used to allow one to report warning information to the other. The message contains the severity level and description of the alarm.

SSL principle (handshake protocol)

Negotiate the relevant security parameters used in data transmission through the SSL handshake protocol, and verify the identity of the peer.

The first phase of the SSL handshake protocol

The client sends a ClientHello message with parameters :

• Version: The protocol version in the message is two byte lengths respectively representing the major and minor versions. The current SSL versions are SSLv1, SSLv2, SSLv3 and TSLv1 (ie SSLv3.1).
• Random number: 32-bit timestamp + 28-byte random sequence, used to calculate the digest of all messages or calculate the master key later.
• Session ID: The SSL session ID is used to identify a session and can be reused.
• List of CipherSuites Supported by the Client (CipherSuite): A list of key suites. The list contains all the key suites supported by the client.
• The list of compression methods supported by the client: The list of compression algorithms supported by the client. Fill in 0 to indicate empty.

When the server receives the ClientHello message containing the above information, the server sends a ServerHello message, including parameters :

• Version: The server takes out the version number in the ClientHello message, and then looks at the list of versions it supports, and selects the highest version number supported by both to determine the version used by the SSL protocol negotiated this time.
• The random number generated by the server: The random number generated here is similar to that in the ClientHello message.
• Session ID: The server detects that the passed Session ID is empty or searches the Session list and does not find the passed Session ID, it will create a new one.

The server selects a set of (CipherSuite) cryptographic algorithms from the cryptographic algorithms suggested by the client

The server selects a compression algorithm from the compression methods suggested by the client

Client Hello packet

Server Hello packet

The second phase of the SSL handshake protocol

Certificate message (optional)

In general, this message needs to be included in the entire SSL handshake process, except that the message does not need to be sent when the session is resumed. The message contains an X.509 certificate, which contains the public key, which is sent to the client to verify the signature or encrypt the message during key exchange.

The server issues its own certificate to the client, allowing the client to verify its identity, and the client takes out the public key in the certificate after passing the verification.

Server Key Exchange (optional)

According to the CipherSuite information contained in the ClientHello message, the key exchange method (such as RSA or DH) is determined, so the Server Key Exchange message will contain a series of parameters required to complete the key exchange.

Certificate Request (optional)

The server sends a CertificateRequest message, asking the client to send his own certificate to verify. The message contains the certificate types (RSA, DSA, ECDSA, etc.) supported by the server and the CA list of all certificate issuing organizations trusted by the server. The client will use this information to filter certificates.

ServerHello Done

This message indicates that the server has sent all the information, and then waits for a message from the client.

Certificate message packet

Server Key Exchange message packet

In Diffie-Hellman, the client cannot calculate the pre-master key by itself; both parties help to calculate it, so the client needs to obtain the Diffie-Hellman public key from the server.

As can be seen from the above figure, the key exchange is also protected by the signature at this time.

ServerHello Done packet

SSL handshake protocol third stage

Certificate (optional)

If the server requests to send the client certificate in the second stage, the client will send its own certificate in this stage. The server-side previously sent Certificate Request message contains the certificate types and CA list supported by the server-side, so the client will select the first certificate that meets these two conditions in its own certificate and send it over. If the client does not have a certificate, a no_certificate warning is sent.

Client Key exchange

According to the random number received from the server before, according to different key exchange algorithms, calculate a pre-master and send it to the server. The server receives the pre-master and calculates the main master. Of course, the client can pass it by itself. The pre-master calculates the main master. In this way, both parties have calculated the symmetric key.

Certificate verify (optional)

This message needs to be sent only after the client has sent its own certificate to the server. It contains a signature to sign the HMAC value (using master_secret) of all handshake messages since the first message.

Client Key exchange data package

The fourth phase of the SSL handshake protocol

A secure connection is established. The client sends a Change Cipher Spec message and copies the negotiated CipherSuite to the current connection state. Then, the client sends a Finished message with the new algorithm and key parameters. This message can check whether the key exchange and authentication process has been successful. It includes a check value to check the message of the client's entire handshake process. The server also sends Change Cipher Spec messages and Finished messages. The handshake process is complete, and the client and server can exchange application layer data for communication.

Server Finished:
Notification of the end of the server handshake.

Use the private key to decrypt the encrypted Pre-master data, and calculate the negotiation key based on the two plaintext random numbers random_C and random_S exchanged before (Client Hello and Server Hello): enc_key=Fuc(random_C, random_S, Pre-Master);
Calculate the hash value of all the previously received messages, and then decrypt the encrypted_handshake_message sent by the client to verify the correctness of the data and key;
send a ChangeCipherSpec (inform the client that it has switched to the negotiated cipher suite state, and is ready to use the cipher suite and Session Secret encryption Data) The
server will also use the Session Secret to encrypt a Finish message and send it to the client to verify the success of the encryption and decryption channel established through the handshake.

SSL session resume

Session resumption means that as long as the client and server have communicated once, they can skip the entire handshake phase and directly transmit data through session resumption.

SSL uses session resumption to reduce the huge overhead caused by the SSL handshake process.

This function is reduced from the original 13 steps of normal coordination to only 6 steps, which greatly reduces the overhead required for the establishment of the SSL VPN tunnel.

In order to speed up the establishment of a handshake and reduce the performance degradation and resource consumption caused by the protocol (the specific analysis is in the following text), the TLS protocol has two types of session caching mechanisms:

Session ID : The session ID is supported by the server and is a standard field in the protocol, so basically all servers support it. The server saves the session ID and negotiated communication information. 1M memory in Nginx can save about 4000 session ID machine-related information, which occupies More server resources;

Session record session ticket : It needs to be supported by both the server and the client. It belongs to an extended field. The support range is about 60% (no reliable statistics and sources). The negotiated communication information is encrypted and sent to the client for storage. Only the server knows the key. Occupies very little server resources.

The comparison between the two is mainly because the location and method of saving the negotiation information are different, similar to the session and cookie in http. When both of them exist, session_ticket (implemented by nginx) is preferred.

The specific process of session recovery (Session ID mechanism):

1. If a connection has been established between the client and the server, the server will return the session ID after the handshake is successful, and save the corresponding communication parameters in the server;

2. If the client needs to establish a connection with the server again, the recorded information is carried in the session ID in client_hello and sent to the server;

3. The server retrieves the cache record according to the received session ID. If the cache is not retrieved, it will follow the normal handshake process;

4. If the corresponding cache record is retrieved, it will return change_cipher_spec and encrypted_handshake_message information. The two messages have similar functions. Encrypted_handshake_message is the hash value of the current communication parameters and master_secret;

5. If the client can verify that the data is encrypted by the server, the client also sends change_cipher_spec and encrypted_handshake_message information; the
server verifies that the data is passed, the handshake is established successfully, and normal encrypted data communication is started.

The specific process of session resumption (session ticket):

1. If a connection has been established between the client and the server, the server will carry the encrypted session_ticket information in the new_session_ticket data, and the client will save it;

2. If the client needs to establish a connection with the server again, the encrypted information is carried in the extended field session_ticket in client_hello and sent to the server together;

3. The server decrypts the sesssion_ticket data. If the decryption fails, it will follow the normal handshake process;

4. If the decryption is successful, return change_cipher_spec and encrypted_handshake_message information, the functions of the two information are similar to the session ID;

5. If the client can verify that the data is encrypted by the server, the client also sends change_cipher_spec and encrypted_handshake_message information;

6. If the server verifies that the data is passed, the handshake is established successfully, and normal encrypted data communication starts.

Principle of SSL (Recording Protocol)

The SSL record protocol is mainly used to implement various high-level protocols for data block segmentation, encryption and decryption, compression and decompression, integrity checking, and encapsulation.

Each SSL record contains the following information:

• Content type
• Protocol version number, currently there are 2.0 and 3.0 versions
• Length of recorded data
• Data payload
• The hash algorithm calculates the message authentication code

detailed steps

(1) Divide the data packets divided by the upper layer into suitable data blocks, but each data block shall not exceed 214 bytes.

(2) Compress each data block, but data information cannot be lost.

(3) Calculate the compressed data message authentication code MAC and add it after the compressed package. After adding, the total length shall not exceed 2262 bytes.

(4) For stream encryption, the compression guarantee and MAC were previously encrypted. For packet encryption, padding can be added after MAC and before encryption. The padding is composed of bytes representing the padding length and padding bytes for the number of moves. The number of padding bytes is such that the total length of the data to be encrypted becomes the minimum number that is an integral multiple of the encrypted packet length.

(5) Add a header to SSL. Including: content type, major version, minor version, compression length and other
information.

Through the above process, the original data is encrypted into a record set of the SSL protocol.