HTTPS implementation principle

The HTTPS protocol is secure because it encrypts the transmitted data using asymmetric encryption. However, IN fact, HTTPS uses symmetric encryption for content transmission. Asymmetric encryption only applies to certificate verification.

The HTTPS process consists of certificate authentication and data transmission. The interaction process is as follows:

① Certificate verification stage:

1) The browser initiates an HTTPS request;

2) The server returns the HTTPS certificate.

3) The client verifies whether the certificate is valid. If the certificate is invalid, an alarm is generated.

② Data transmission stage:

1) Generate random numbers locally after certificate verification is valid;

2) Encrypt the random number through the public key and transmit the encrypted random number to the server;

3) The server decrypts random numbers through private keys;

4) The server constructs a symmetric encryption algorithm through the random number passed in by the client, encrypts the returned result content and transmits it.

Why is data transmitted symmetrically encrypted?

First of all: asymmetric encryption is very inefficient in encryption and decryption, and HTTP application scenarios usually have a large number of end-to-end interactions, asymmetric encryption efficiency is unacceptable.

In the HTTPS scenario, only the server saves the private key. A pair of public and private keys can only be used for one-way encryption and decryption. Therefore, the content transmission encryption in HTTPS is symmetric rather than asymmetric.

Why do I need a CA to issue a certificate?

HTTP is considered insecure because the transmission process is easy to be tapped by listeners and forged servers, while HTTPS mainly solves the security problem of network transmission.

First, we assume that there is no certification authority and that anyone can create a certificate, which presents a security risk known as the classic “man-in-the-middle” problem.

As shown in the figure above, the process principle is as follows:

  • 1) Local requests are hijacked (e.g. DNS hijacking, etc.) and all requests are sent to the middleman’s server;

  • 2) The middleman server returns the middleman’s own certificate;

  • 3) The client creates a random number, encrypts the random number through the public key of the middleman certificate, and sends the random number to the middleman. Then the client constructs symmetric encryption based on the random number to encrypt and transmit the transmitted content.

  • 4) Because the middleman has the random number of the client, it can decrypt the content through the symmetric encryption algorithm;

  • 5) The middleman initiates a request to the regular website with the content requested by the client;

  • 6) Because the communication between the middleman and the server is legal, the regular website returns the encrypted data through the established secure channel;

  • 7) Middlemen decrypt the content by means of symmetric encryption algorithms established with regular websites;

  • 8) The middleman encrypts and transmits the data returned by the regular content through the symmetric encryption algorithm established with the client;

  • 9) The client decrypts the returned result data through the symmetric encryption algorithm established with the middleman.

The difference between symmetric and asymmetric encryption:

Symmetric encryption: Use the same secret key for encryption and decryption

Asymmetric encryption: public and private keys