Detailed explanation of HTTPS encryption process

HTTPS uses a "hybrid encryption" method that combines symmetric encryption and asymmetric encryption :

  • Asymmetric encryption is used to exchange "session keys" before communication is established , and asymmetric encryption is no longer used in the future.

  • During the communication process, the plaintext data is encrypted by using the symmetric encrypted "session key".

Reasons for adopting the "hybrid encryption" method:

  • Symmetric encryption uses only one key, and the operation speed is fast. The key must be kept secret, and secure key exchange cannot be achieved.

  • Asymmetric encryption uses two keys: a public key and a private key. The public key can be distributed arbitrarily while the private key is kept secret, which solves the key exchange problem but is slow.

How does HTTPS establish a connection?

Basic process of SSL/TLS protocol:

  • The client requests and verifies the server's public key from the server.

  • The two parties negotiate to produce a "session key".

  • The two parties use the "session key" for encrypted communication.

The first two steps are the establishment process of SSL/TLS, that is, the handshake phase.

The "handshake phase" of SSL/TLS involves four communications, as shown in the following figure:

The detailed process of SSL/TLS protocol establishment:

1. ClientHello

First, the client initiates an encrypted communication request to the server, that is,  ClientHello a request.

In this step, the client mainly sends the following information to the server:

(1) The SSL/TLS protocol version supported by the client, such as TLS 1.2 version.

(2) The random number ( ) generated by the client Client Randomis used later to generate the "session key".

(3) The list of cipher suites supported by the client, such as the RSA encryption algorithm.

2. SeverHello

After the server receives the client request, it sends a response to the client, that is  SeverHello. The content of the server response is as follows:

(1) Confirm the SSL/TLS protocol version, if the browser does not support it, close the encrypted communication.

(2) The random number ( ) produced by the server Server Randomis used later to generate the "session key".

(3) List of confirmed cipher suites, such as RSA encryption algorithm.

(4) The digital certificate of the server.

3. Client response

After receiving the server's response, the client first confirms the authenticity of the server's digital certificate through the browser or the CA public key in the operating system.

If there is no problem with the certificate, the client will take the server's public key from the digital certificate, then use it to encrypt the message, and send the following information to the server:

(1) A random number ( pre-master key). The random number will be encrypted with the server's public key.

(2) Encrypted communication algorithm change notification, indicating that subsequent information will be encrypted with the "session key".

(3) The client handshake end notification indicates that the handshake phase of the client has ended. This item also makes a summary of the data of all previous content, which is used for verification by the server.

The random number in the first item above is the third random number in the entire handshake phase, so that the server and the client have three random numbers at the same time, and then use the encryption algorithm negotiated by both parties to generate the "session key" for this communication .

4. The server's last response

After receiving the third random number ( ) from the client pre-master key, the server calculates the "session key" for this communication through the negotiated encryption algorithm. Then, send the final message to the client:

(1) Encrypted communication algorithm change notification, indicating that subsequent information will be encrypted with the "session key".

(2) The server handshake end notification indicates that the server's handshake phase has ended. This item also makes a summary of the data of all previous content, which is used for client verification.

At this point, the handshake phase of the entire SSL/TLS is over. Next, the client and the server enter into encrypted communication, which uses the ordinary HTTP protocol completely, but uses the "session key" to encrypt the content.

This article is excerpted from the Internet, for details, please refer to: HTTP Common Interview Questions

 

Guess you like

Origin blog.csdn.net/m0_59952648/article/details/131597514