Keyless SSL: The Nitty Gritty Technical Details is Cloudflare’s documentation for releasing Keyless SSL (HTTPS CDN hosting service without a private key), It explains the TLS handshake process with rich illustrations and a well-organized text structure.

This article will build on this article, along with some other references, to compile a description of the TLS handshake process.

An overview of the

The TLS handshake is generally divided into the RSA handshake and the DH handshake. The difference between the two is that the Cipher Suite is used. These concepts will be explained in the following sections.

RSA handshake

Figure: RSA handshake process

concept

First, explain some of the unfamiliar concepts in the picture below:

  1. Cipher Suite: A unique identifier consisting of the names of a set of encryption algorithms, used by the client to ask the server for the encryption scheme used for TLS communication, as shown in step 1. Take a Cipher Suite with an RSA handshake as an example:
TLS_RSA_WITH_AES_128_GCM_SHA256
Copy the code

Cipher Suite generally consists of four algorithms: (1) A Key Exchange algorithm, which is usually an asymmetric encryption algorithm. It is used when the client uses the public Key to encrypt the Premaster secret and the server uses the private Key to decrypt the secret. In this example, RSA is used. (2) An Authentication algorithm, usually an asymmetric encryption algorithm, is still RSA in this example. (In RSA handshake, key exchange and identity Authentication use the same set of keys. Only in the DH handshake, two sets of keys generated by two different encryption algorithms are used to perform the two operations respectively. A pair of keys does only one thing to ensure Perfect forward secrecy. For more details, see DH handshake. (3) An Encryption algorithm, usually a symmetric Encryption algorithm, uses the Session key generated by the handshake as the public key to encrypt the message body from the application layer. In this example, AES_128_GCM, which means 128-bit AES encryption based on GCM grouping (4) A Message Authentication Code (MAC) algorithm, usually a Hash function, Therefore, it is also called HMAC, which is used for digital signature of content, that is, to verify message integrity, and authentication of the peer end. In this example, SHA256 indicates that the 256-bit SHA algorithm is adopted.

  1. Client Random number: This is a 32-byte sequence generated by the Client, which is unique in each connection. It is usually composed of a 4-bit timestamp and a 28-bit random byte. This kind of random number is commonly called nonce
  2. Server random number: The Server random number is the same as the client random number, except that it is generated by the Server
  3. Pre-master secret: This is a 48-byte BLOB that is typically generated using a Pseudorandom Function using a combination of client-side and server-side random numbers
  4. Session key: This is the ultimate purpose of THE TLS handshake. At the end of the handshake, both the client and the server can have the Session key. Therefore, the client and server can use the Session key as the symmetric encryption key to encrypt and decrypt the information of both parties

Carding process

Having explained the concept, here’s how the handshake works:

  1. Client Hello: The Client sends a Hello message to initiate a handshake. The message contains TLS protocol version to be used by the Client, Client Random, Cipher Suite, and other necessary information
  2. Server Hello: The Server receives the Hello message from the client and determines the final handshake type based on the encryption suite list provided in the message. Finally, a Server Hello message is returned to the client. The message contains the Server random number, the final list of encryption suites to use, and the Server certificate (such as the HTTPS certificate, which contains the RSA generated public key and the Server domain name).
  3. The client verifies the certificate and generates the pre-master key: After the certificate sent by Server Hello is verified to be credible and the site is correctly owned, the Client combines Client Random with Server Random. The pre-master secret is generated using Pseudorandom Function, and the pre-master key is encrypted using the public key in the certificate and sent to the server
  4. The server uses the private key to decrypt and obtain the pre-master key: After receiving the encrypted pre-master secret, the server uses the private key generated by RSA and paired with the public key to decrypt and obtain the same pre-master secret as the client
  5. Generate Session key: At this point, both the Client and the Server obtain the same Client random, Server random and pre-master secret through the process of key exchange. Then the Client and the Server can deduce the same Session key respectively. Subsequent communications will use this Session key as the AES_128_GCM key for encryption and decryption
  6. The client and server exchange encrypted end-of-handshake messages and perform HMAC authentication: After the Session key is generated, the client and server use the Session key to encrypt the message body and exchange a Finish message, indicating that the handshake is officially completed and both parties can normally use the Session key to transmit encrypted data. Also verify the integrity of the handshake phase using HMAC digital signature validation in the Finish message

During this process, if any error occurs (such as server certificate authentication failure or integrity verification error), an Alert packet is sent to the Alert protocol layer for error handling.

DH handshake

Figure: DH handshake process

Differences with RSA handshake

As described in the previous chapter, the RSA handshake uses the same set of keys generated by RSA in the process of key exchange and identity authentication, which brings forward security problems, namely the risk of server private key leakage. In normal communication, the client through the server to the public key encryption, and the server will be decrypted to the client’s information, but the problem is that the server’s public key is included in the certificate from the server, the validity of the certificate from the server is usually for several years, this means that the private key from the server if the leak, All messages that were previously encrypted using this public key can then be decrypted. In the DH handshake described in the preceding figure, 2A and 2b indicate digital signature processes (the same as those in RSA), and 3 and 4 indicate key exchange processes based on the DH algorithm.

The DH algorithm commonly used in TLS is a variant of Elliptic Curve Diffie-Hellman Key Exchange. Therefore, ECDHE is the abbreviation of the ALGORITHM used in key exchange.

DH handshake adds ecDHE-based key exchange process, which exchanges a set of DH parameters generated by random numbers, and finally calculates Premaster Secret based on client DH parameters and server DH parameters using the same ECDHE algorithm. This step is very important. Due to the increase in shake hands every time a set of characteristics to randomness of parameters, makes the attacker even if access to the use of all the private key, a handshake also can decrypt the contents of this time, communication, and for all communications powerless before, because every communication to the private key is not the same, for the agreement gives the communication prior to security. In the end, Premaster Secret will combine Client random and Server Random generated in the previous digital signature process to generate the symmetric Session key for communication encryption.

Carding process

Based on the above description of the differences between THE DH handshake and the RSA handshake, the DH handshake process is summarized, for example, Cipher Suite:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Copy the code
  1. Client Hello: The Client sends a Hello message to initiate a handshake. The message contains TLS protocol version to be used by the Client, Client Random, Cipher Suite, and other necessary information
  2. Server Hello: the Server returns the Cipher Suite, the Server random number, and the certificate containing the RSA public key. The RSA private key is used to sign all the previous packets (Client Random, Server Random, and public key certificate) and send them to the Client. A random DH parameter for ECDHE key exchange is also returned
  3. Client check and send DH Parameter to obtain Session key: The Client uses the public key to verify the digital signature sent by the server. After the verification succeeds, DH parameters are generated randomly and sent to the server. In this case, the Client has the Client DH Parameter and Server DH Parameter, and can use the ECDHE algorithm to generate Premaster Secret. At this point, the Client has Client Random, Server Random and Premaster Secret, and the final Session key can be deduced according to these three parameters
  4. The Server receives the DH Parameter from the Client and obtains the Session key: The Server receives the DH Parameter from the Client and derives the final Session key
  5. The client and server exchange encrypted end-of-handshake messages and perform HMAC authentication: After the Session key is generated, the client and server use the Session key to encrypt the message body and exchange a Finish message, indicating that the handshake is officially completed and both parties can normally use the Session key to transmit encrypted data. Also verify the integrity of the handshake phase using HMAC digital signature validation in the Finish message

The Illustrated TLS Connection is an implementation of TLS 1.2 DH handshake. Its official website introduces The details of DH handshake process in detail, including The structure of each packet and The detailed process of each calculation step, which is a very good extended reading material. In this implementation, the process of deriving Session keys from Client Random, Server Random, and Premaster Secret is a set of algorithms based on HMAC.

Reference: TLS protocol analysis and modern encryption communication protocol design Keyless SSL: The Nitty Gritty Technical Details TLS 1.3 Popular Science — New features and protocols to implement The Illustrated TLS Connection

HTTP – TLS handshake protocol