Network | Comic: What is the HTTPS protocol?

What is HTTP?

The full name of HTTP protocol is Hyper Text Transfer Protocol, which is located in the application layer of the TCP/IP four-layer model.

The HTTP protocol communicates between the client and the server through a request/response method.

All this seems great, but the HTTP protocol has a fatal flaw: it is not secure enough.

HTTP protocol information transmission is completely in plain text, without any encryption, which is equivalent to "running naked" on the network. What problems will this cause? Let's make an analogy:

Xiao Hui is the client, and Xiao Hui’s colleague Xiao Hong is the server. One day, Xiao Hui tried to send a request to Xiao Hong.

However, since the transmitted information is in plain text, it is possible for a middleman to maliciously intercept or even tamper with it. This behavior is called a man-in-the-middle attack.

How to encrypt?

Xiaohui and Xiaohong can agree on a symmetric encryption method in advance and agree on a randomly generated key. In subsequent communications, the sender of the information uses the key to encrypt the information, and the receiver of the information uses the same key to decrypt the information.

Is it absolutely safe to do this? Not really.

Although we have encrypted the plain text in subsequent communications, the first communication that agreed on the encryption method and key is still plain text. If the first communication is intercepted, the key will be leaked to the middleman, who can still decrypt all subsequent communications.

What can we do about this? Don't worry, we can use asymmetric encryption to provide an extra layer of protection for the transmission of keys.

Asymmetric encryption includes a public key and a private key. Plain text can be encrypted with the public key and decrypted with the private key, or encrypted with the private key and decrypted with the public key.

When Xiaohui and Xiaohong establish communication, Xiaohong first sends her public key Key1 to Xiaohui:

After receiving Xiaohong's public key, Xiaohui generates a key Key2 for symmetric encryption, encrypts Key2 with the public key Key1 just received (a bit confusing here), and sends it to Xiaohong:

Xiaohong uses her asymmetric private key to decrypt the public key Key1 and obtain the content of Key2. From then on, the two can use Key2 for symmetric encrypted communication.

During the communication process, even if the middleman intercepts the public key Key1 at the beginning, he cannot decrypt it because he does not know what the private key is.

What a bad idea! Although the middleman does not know what Xiaohong's private key is, after intercepting Xiaohong's public key Key1, he can steal the data and generate another pair of public and private keys, and send his own public key Key3 to Xiaohui.

Xiao Hui didn't know that the public key had been secretly changed, and thought that Key3 was Xiao Hong's public key. So according to the previous process, he used Key3 to encrypt the symmetric encryption key Key2 he generated and sent it to Xiao Hong.

This time the communication was intercepted by the middleman again. The middleman first used his own private key to decrypt Key3 and obtained Key2. He then re-encrypted it with Key1 sent by Xiaohong and sent it to Xiaohong.

In this way, although the subsequent communications between the two people are symmetrically encrypted using Key2, the middleman already has Key2 and can therefore easily decrypt it.

What is the solution? Should we encrypt the public key again? This will only lead to an endless chicken-and-egg dilemma.

At this time, we need to introduce a third party, an authoritative certificate authority (CA) to solve the problem.

What exactly is a certificate? A certificate contains the following information:

For the sake of explanation, we have simplified it here and only listed some key information. As for the use of these certificate information, we can understand it by looking at the specific communication process.

The process is as follows:

1. Xiaohong, who is the server, first sends her public key to the certificate authority and applies for a certificate from the certificate authority.

2. The certificate authority also has a pair of public and private keys. The authority uses its own private key to encrypt Key1 and generates a certificate signature through the server URL and other information. The certificate signature is also encrypted by the institution's private key. After the certificate is produced, the institution sends the certificate to Xiaohong on the server.

3. When Xiaohui requests communication from Xiaohong, Xiaohong no longer directly returns her public key, but returns the certificate she applied for to Xiaohui.

4. After receiving the certificate, the first thing Xiao Hui needs to do is to verify the authenticity of the certificate. It should be noted that major browsers and operating systems have maintained the names and public keys of all authoritative certificate authorities. Therefore, Xiao Hui only needs to know which authority issued the certificate, and then he can find the corresponding authority public key locally and decrypt the certificate signature.

Next, Xiao Hui generates a certificate signature for himself according to the same signing rules. If the two signatures are consistent, the certificate is valid.

After successful verification, Xiao Hui can safely use the organization's public key again to decrypt Xiao Hong's public key Key1 on the server.

5. Like before, Xiaohui generates his own symmetric encryption key Key2, encrypts Key2 with the server public key Key1, and sends it to Xiaohong.

6. Finally, Xiaohong uses her private key to decrypt the message and obtains the symmetric encryption key Key2. Then the two begin to communicate using Key2 for symmetric encryption.

Under such a process, we might as well think about whether the middleman still has room to do bad things.

Note: The newly launched TLS protocol is an upgraded version of the SSL 3.0 protocol, and its general principles are the same as those of the SSL protocol.

[[273369]]