Understand SSL/TLS in one article

1 Overview

Secure Sockets Layer (SSL, Secure Sockets Layer) is a security protocol based on public key cryptography and X.509 digital certificate technology that provides identity authentication and data transmission confidentiality and integrity for network communications.

In 1994, Netscape proposed SSL1.0. After several revisions, SSL3.0 was officially released in 1996. In 1997, the Internet Engineering Task Force (IETF, Internet Engineering Task Force) released an Internet draft based on the SSL protocol: Transport Layer Security (TLS, Transport Layer Security) . In 1999, IETF released the official industry standard RFC2246 , and TLS/SSL is becoming a communication security standard.

SSL/TLS is an encryption protocol located between the transport layer and the application layer (belonging to the implementation of the Socket layer). It is transparent to the application layer. The application layer data is encrypted by passing it to the SSL layer, and the SSL header is added, and then passed to the transport layer.

Both SSL/TLS can provide identity authentication, confidentiality, and integrity services. Although all versions of the SSL series have been deprecated, TLS is a subsequent version of SSL, and everyone is still accustomed to using the name SSL.

2. Composition of the agreement

The SSL protocol consists of three parts:

• Handshake protocol: negotiate encryption algorithm, MAC algorithm and session key
• Protocol of Record: Encrypt and sign the data exchanged
• Alerting Protocol: Solving Problems as They Go Ahead

2.1 Handshake protocol (Handshake protocol)

The handshake protocol is the first protocol executed between the client and the server to establish an SSL connection. It is completed before the data is transmitted. The server and the client use this protocol to identify each other's identity, negotiate encryption algorithms, MAC algorithms, and session keys used to encrypt data.

(1) Establish security capabilities

• Client Hello: When the client connects to the server for the first time, it will be Client Hellosent to the server as the first message, including the encryption components (cipher_suite) supported by the client: encryption algorithm, compression algorithm, digest algorithm, and this connection client Generated random numbers. If the client wants to restore the last session, it also needs to send the session ID.

• Server Hello: Server HelloIt is the reply from the server to the client Client Hello, including the encryption algorithm, compression algorithm, and digest algorithm selected Client Helloby this session, the session ID (session ID) determined by the server, and the random number of the server.

(2) Server authentication and key exchange

The client uses the server response message to complete the authentication of the real identity of the server.

• （Server) Certificate: If it is required to verify the server, the server Server Hellowill send its certificate (certificate) after the message, usually the X.509v3 version of the certificate.

• Server Key Exchange: This message complements Server Hellothe cipher suite previously in the message declaration, providing the client with the algorithm variables needed to continue the communication (depending on the selected algorithm).

• Certificate Request: If the server needs to authenticate the identity of the client, it will send it to the client Certificate Request. This message contains the certificate type and trusted CA certificate sequence that the server can identify.

• Server Hello Done: This message indicates Server Hellothe end, waiting for the response from the client. After receiving the information, the client checks whether the Certificate provided by the server is valid, and whether the Hello parameter of the server is acceptable.

(3) Client authentication and key exchange

• （Client） Certificate: When the server requests , the client sends this information after Certificatereceiving the server's request . Server Hello DoneIf the client does not have a suitable Certificate, a "no certificate" warning message is sent.

• Client Key Exchange: The message content depends on the key exchange algorithm type

  • If the RSA algorithm is selected, the message contains the pre-encrypted master secret (pre-master secret) encrypted by the RSA public key , where the RSA public key is the public key in the server certificate or Server Key Exchangethe RSA public key temporarily generated by the server .
  • If the DH algorithm is selected, the message contains the public value generated by the client using the DH algorithm parameters sent from the server, and the public value will be generated as a pre-encrypted master key.

• Certificate Verify: This message is used to provide client certificate verification, and it is sent only after the client capable of signing sends the certificate.

(4) Complete the handshake

The client and the server use pre_master_secret to generate the real master key master_secret , and then use the master key to generate the session key session_keys , and then send each other Change Cipher Specand confirm.

• Change Cipher Spec: It is used by the sender to inform the receiver that the sender has completed the change of the encryption specification and is ready to use the negotiated cipher suite (Cipher Suite) and session key (Session Key) to encrypt and transmit the data, which is reflected in the data packet as a word section data.

• Finished: The sender uses the negotiated encryption suite (Cipher Suite) and session key (Session Secret) to encrypt a piece of Finishdata and send it to the receiver. After receiving Finishethe information, the receiver must check whether the content is correct to establish an encryption and decryption channel successfully .

The client and the server Finishedverify the information and confirm that the encrypted channel has been successfully established, and the two parties can use the generated session keys (Session keys) to encrypt and transmit data.

Alert Protocol

When the client and server detect an error, they send each other an alert message. In case of a fatal error, the algorithm immediately terminates the session and closes the SSL connection, while deleting related session records, secrets and keys.

2.2 Record Protocol

After the client and server complete the authentication and determine the algorithm used for security information exchange, they enter the SSL record protocol, which mainly provides two services:

• Data Confidentiality: The transmitted data is encrypted using the secret key defined by the handshake protocol.
• Message Integrity: Computing the message authentication code using the secret key with MAC defined by the handshake protocol.

The recording protocol receives the message sent by the application program, divides the data into pieces (cut into small blocks that are easy to manage), and then chooses whether to compress these blocks, plus the message authentication code of this block, and combines the data block with The MAC is encrypted together, and the SSL record header is added and sent out through TCP. The party receiving the data decrypts, verifies, decompresses, and reassembles the data, restores the content of the message, and transmits it to the upper-layer application.

• (1) Segmentation: Each upper layer application data is divided into $2^{14}$ (16K) or smaller data blocks.
• (2) Compression: Compression is optional and lossless.
• (3) Add MAC: Use Hash functions such as MD5 and SHA to generate message digest MAC, and add message authentication MAC to compressed data for data integrity check.
• (4) Encryption: Encrypt the compressed data and MAC to ensure the confidentiality of the data.
• (5) Additional SSL header output

3. Cipher suites and key generation

(1) Cipher suite (cipher_suite)

A cipher suite is a selected set of cryptographic primitives and other parameters, including key exchange algorithms, authentication algorithms, data encryption algorithms, and hash algorithms.

As TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA156indicated:

• Key exchange: ECDHE
• Authentication: RSA
• Data encryption algorithm: AES_128_GCM
• MAC：SHA156

(2) Key generation

• PreMaster secret : The PreMaster Secret is generated by the client Client Key Exchangeusing encryption algorithms such as RSA or Diffie-Hellman, and is encrypted with the public key of the server and sent to the server. The server decrypts it with the private key to obtain the PreMaster secret .

• Master key (Master secret) : The master key (Master secret) is used to generate various encryption algorithm keys, the server and the client use the PreMaster secret, the random number generated by the client in the Hello phase, and the server in the Hello phase The generated random numbers are generated according to the following rules:

Master secret=
MD5(premaster secret + SHA('A'  + premaster secret + ClientHello.random + ServerHello.random))+
MD5(premaster secret + SHA('BB' + premaster secret + ClientHello.random + ServerHello.random))+
MD5(premaster secret + SHA('CCC'+ premaster secret + ClientHello.random + ServerHello.random))

The master key first generates a key block (Key Block) of sufficient length through a series of hash operations. The length of the key block is greater than or equal to the length of various encryption keys required by SSL. Then SSL divides the data in the key block into individual encryption keys, and if there is any remaining data in the Key block after dividing, the remaining data will be discarded directly.

When the client sends data:

• First append the dataClient write MAC key
• Client write encryption keyThen encrypt the packets using
• After receiving the ciphertext, the server uses Client write encryption keydecryption
• The server Client write MAC keyverifies the integrity of the data using

When the server sends data:

• First append the dataServer write MAC key
• Server write encryption keyThen encrypt the packets using
• After receiving the ciphertext, the client uses Server write encryption keydecryption
• The client Server write MAC keyverifies the integrity of the data using

4. SSL protocol application mode

(1) Anonymous SSL connection

This mode is the most basic mode of SSL secure connection, easy to use, common browsers support this mode, very suitable for one-way secure data transmission applications. A typical application is to use anonymous SSL to connect to the website in order to prevent the leakage of private information (such as credit card number, password, phone number, etc.) when the user registers on the website.

In this mode, the client does not have a digital certificate, and the user accesses the server anonymously. The server has a digital certificate to realize server authentication, so that the user can confirm that it is the site he wants to visit. During the first SSL connection, the client needs to download the server certificate, then randomly generate a key, and then use this key to perform the SSL handshake agreement. After a session is completed, the key is discarded .

(2) Peer-to-peer security services

In this mode, both sides of the communication can initiate and receive SSL connection requests. They are both servers and clients. Both parties have digital certificates to realize two-way authentication between the server and the client. The communication parties can be applications or security protocol servers (security protocol The proxy server is equivalent to an encryption/decryption gateway, which converts the access of the internal network into SSL data packets, and decrypts the SSL data packets when receiving.).