Illustration of SSL/TLS protocols

This week, cloudflare announced that it began to provide the keyless service, that is, you put the website on their CDN, without providing your own private key, you can also use SSL encrypted links.

After reading cloudflare's instructions (here and here), I suddenly realized that this is an excellent example to illustrate the running mechanism of the SSL/TLS protocol. It is illustrated and easy to understand.

Next, I will use these images as an example to explain the SSL protocol in conjunction with the "SSL/TLS Protocol operating mechanism overview" I wrote six months ago.

　　I. handshake process of the SSL protocol

Before encrypted communication starts, the client and server must establish a connection and exchange parameters. This process is called handshake ).

Assume that the client is Alice and the server is Bob. The entire handshake process can be explained (click to see the big picture ).

The handshake stage is divided into five steps.

Step 1: Alice provides the Protocol version number, a random number (client random) generated by a client, and the encryption method supported by the client.

Step 2 bob confirms the encryption method used by both parties and provides a digital certificate and a server-generated random number (server random ).

Step 3, Alice confirms that the digital certificate is valid, then generates a new random number (premastersecret), and uses the public key in the digital certificate to encrypt the random number and send it to Bob.

Step 4 Bob uses his private key to obtain the random number (premaster secret) sent by Alice ).

Step 5 Alice and Bob use the preceding three random numbers to generate a session key based on the agreed encryption method to encrypt the next conversation.

The five steps above are shown in the figure below.

　　Ii. Roles of private keys

Note three points in the handshake phase.

(1) generating a conversation key requires a total of three random numbers.

(2) After a handshake, the conversation uses "conversation key" encryption (symmetric encryption). The public and private keys of the server are only used to encrypt and decrypt "conversation key" (asymmetric encryption ), no other functions.

(3) Place the public key of the server in the digital certificate of the server.

From the second point above, we can see that the public key and private key of the server only need to be used once during the entire dialog process (the handshake phase and the subsequent DIALOG. This is the root cause for cloudflare's ability to provide the keyless service.

Some customers (such as banks) want to use external CDN to speed up access to their own websites. However, for security reasons, private keys cannot be handed over to CDN service providers. In this case, you can leave the private key on your server and only decrypt the conversation key. Other steps are completed by the CDN service provider.

The bank server only participates in Step 4. The private key is no longer used in subsequent conversations.

　　Iii. DH algorithm handshake stage

The entire handshake phase is not encrypted (and cannot be encrypted) and is in plain text. Therefore, if someone listens to the communication, he can know the encryption method selected by both parties, and two of the three random numbers. The security of the entire call depends only on whether the third random number (premaster secret) can be cracked.

Theoretically, as long as the server's public key is long enough (for example, 2048 bits), The premaster secret can be prevented from being cracked. However, to ensure security, we can consider changing the algorithm in the mobile phase from the default RSA algorithm to the Diffie-Hellman algorithm (DH algorithm ).

After the DH algorithm is used, the premaster secret does not need to be passed. The two sides can calculate the random number as long as they exchange their respective parameters.

Step 3 and Step 4 are changed from passing the premaster secret to passing the parameters required by the DH algorithm, and then both parties calculate the premaster secret respectively. This improves security.

　　Iv. Session recovery

The handshake phase is used to establish an SSL connection. If the conversation is interrupted for some reason, a new handshake is required.

There are two methods to restore the original session: Session ID and session ticket.

The idea of session ID is very simple, that is, each session has a number (session ID ). If the dialog is interrupted, the client can re-use the existing "dialog key" as long as the client gives this number and the server has this number record during the next reconnection ", instead of generating a new one.

The client provides the session ID. When the server confirms that the number exists, both parties no longer perform the remaining steps in the handshake phase, and directly use the existing conversation key for encrypted communication.

Session ID is currently supported by all browsers, but its disadvantage is that the session ID is always retained on only one server. Therefore, if a client request is sent to another server, the conversation cannot be restored. Session ticket was born to solve this problem. Currently, it is only supported by Firefox and chrome.

The client no longer sends the session ID, but sends a session ticket sent by the server in the previous dialog. This session ticket is encrypted and can only be decrypted by the server, including the main information of this conversation, such as the conversation key and encryption method. After the server receives the session ticket, it does not have to generate a new session key after decryption.

 

Http://kb.cnblogs.com/page/504228/

Illustration of SSL/TLS protocols