First, the handshake process of the SSL protocol
Before starting encrypted communication, the client and server must first establish a connection and exchange parameters, a process called handshake.
Assuming that the client is called Alice and the server is called Bob, the whole handshake process can be illustrated by the following figure (click to enlarge).
The handshake phase is divided into five steps.
In the first step, Alice gives the protocol version number, a random number generated by the client (Client random), and the encryption method supported by the client.
In the second step, Bob confirms the encryption method used by both parties, and gives the digital certificate and a random number (Server random) generated by the server.
In the third step, Alice confirms that the digital certificate is valid, then generates a new random number (Premaster secret), and uses the public key in the digital certificate to encrypt the random number and send it to Bob.
In the fourth step, Bob uses his private key to obtain the random number (ie Premaster secret) sent by Alice.
In the fifth step, Alice and Bob use the previous three random numbers to generate a "session key" according to the agreed encryption method, which is used to encrypt the entire dialogue process that follows.
The above five steps are drawn into a picture, which is as follows.
2. The role of the private key
There are three things to note in the handshake phase.
(1) A total of three random numbers are required to generate the session key.
(2) The dialogue after the handshake is encrypted with the "dialogue key" (symmetric encryption), and the server's public and private keys are only used to encrypt and decrypt the "dialogue key" (asymmetric encryption), and have no other functions.
(3) The server public key is placed in the server's digital certificate.
As can be seen from the second point above, the server's public key and private key only need to be used once during the entire dialogue process (handshake phase and subsequent dialogues). This is the fundamental reason why CloudFlare is able to provide Keyless services.
Some customers (such as banks) want to use an external CDN to speed up their website access, but for security reasons, the private key cannot be handed over to the CDN service provider. At this time, you can leave the private key on your own server and only use it to decrypt the session key, and let the CDN service provider complete other steps.
In the above figure, the bank's server only participates in the fourth step, and the private key will no longer be used in subsequent conversations.
3. The handshake phase of the DH algorithm
The entire handshake phase is not encrypted (and cannot be encrypted), it is all plaintext. So, if someone eavesdrops on the communication, he can know the encryption method chosen by both parties, as well as two of the three random numbers. The security of the entire call only depends on whether the third random number (Premaster secret) can be cracked.
Although theoretically, as long as the server's public key is long enough (such as 2048 bits), then the Premaster secret can be guaranteed not to be cracked. But in order to be safe enough, we can consider changing the algorithm of the grasping phase from the default RSA algorithm to the Diffie-Hellman algorithm (DH algorithm for short).
After adopting the DH algorithm, the Premaster secret does not need to be passed, and the two parties only need to exchange their respective parameters to calculate the random number.
In the above figure, the third and fourth steps change from passing the Premaster secret to passing the parameters required by the DH algorithm, and then both parties calculate the Premaster secret separately. This improves security.
Fourth, the recovery of the session
The handshake phase is used to establish an SSL connection. If, for some reason, the conversation is interrupted, a new handshake is required.
At this time, there are two ways to restore the original session: one is called session ID, and the other is called session ticket.
The idea of session ID is very simple, that is, each conversation has a number (session ID). If the conversation is interrupted, when the next reconnection, as long as the client gives this number and the server has a record of this number, both parties can reuse the existing "conversation key" without having to regenerate one.
In the above figure, the client gives the session ID, and the server confirms that the ID exists. The two parties will not perform the remaining steps of the handshake phase, but directly use the existing session key for encrypted communication.
Session ID is a method currently supported by all browsers, but its disadvantage is that session ID is often only kept on one server. So, if the client's request goes to another server, there is no way to resume the conversation. The session ticket was born to solve this problem and is currently only supported by Firefox and Chrome browsers.
In the above figure, the client no longer sends the session ID, but a session ticket sent by the server in the last conversation. This session ticket is encrypted and can only be decrypted by the server, which includes the main information of the session, such as the session key and encryption method. When the server receives the session ticket, there is no need to regenerate the session key after decryption.