Interviewer: "Do you know when HTTPS is insecure?"

Interviewer: "Do you know the encryption process of HTTPS?"

Me: "That's for sure."

Interviewer: "Then do you know when HTTPS is insecure?"

Here...."

The more you feel that you are more talented, continue to study hard! ! !

What is a man-in-the-middle attack?

Man-in-the-middle attack ( MITM ) in the field of cryptography and computer security means that the attacker establishes independent connections with the two ends of the communication and exchanges the data they receive, making the two ends of the communication think that they are passing through a private connection Talk to the other party directly, but in fact the entire session is completely controlled by the attacker [1] . In a man-in-the-middle attack, an attacker can intercept a call between two communicating parties and insert new content. In many cases this is straightforward (for example, a man-in-the-middle attacker within acceptable range of an unencrypted Wi-Fi  access point can insert himself into the network as a man-in-the-middle).

The prerequisite for a successful man-in-the-middle attack is that the attacker can disguise himself as each terminal participating in the session, and cannot be detected by other terminals. A man-in-the-middle attack is a (lack of) mutual authentication attack. Most encryption protocols have specially added some special authentication methods to prevent man-in-the-middle attacks. For example, the SSL protocol can verify whether the certificate used by one or both parties participating in the communication is issued by an authoritative and trusted digital certificate certification authority , and can perform mutual identity authentication.

The above definition comes from Wikipedia. Let's give a popular example to understand man-in-the-middle attacks:

 

1. A sends a message to B, but it is intercepted by C:

A: "Hi B, I'm A. Give me your public key"

1. C forwards the intercepted message to B; at this time, B cannot tell whether the message is really from A:

C: "Hi B, I'm A. Give me your public key"

1. B responds to A's message with his public key:

B -> B's public key -> C

1. C replaces B's key in the message with its own key, and forwards the message to A, claiming it is B's public key:

C -> C's public key -> A

1. A uses what it thinks is B's public key to encrypt a message that only B can see

A -> xxx -> C

1. C modifies with B's key

C -> zzz -> B

This is the whole process of man-in-the-middle attack.

How does a man-in-the-middle attack work in HTTPS?

First let me review the entire process of HTTPS:

Review the HTTPS process

 

This is the original process of HTTPS, but when we have a middleman server, the whole process becomes as follows.

It is recommended to draw a picture for this process, which is easy to understand

1. The client sends an HTTPS connection establishment request to the server, which is intercepted by the middleman server.
2. The middleman server sends an HTTPS connection establishment request to the server
3. The server sends the public key certificate to the client, which is intercepted by the middleman server
4. The intermediary server verifies the validity of the certificate and obtains the public key from the certificate
5. The middleman server sends its own public key certificate to the client

Notice! At this time, HTTPS may have problems. The client will ask you: "There is a problem with the certificate of this website. Are you sure you want to trust this certificate?" So from this point of view, there is actually no problem with the entire process of HTTPS. The main problem is that the client is not secure enough.

1. The client verifies the validity of the certificate and obtains the public key from the certificate
2. The client generates a random number, encrypts it with the public key, sends it to the server, and the intermediary server intercepts it
3. The intermediary server encrypts with the private key to obtain a random number, and then uses the random number to generate an encryption key according to the algorithm, and the client and the intermediary server encrypt according to the symmetric encryption key.
4. The middleman server encrypts with the public key of the certificate given by the server, and when sending it to the server
5. The server gets the information, decrypts it, and then uses the random number to generate a symmetric encryption algorithm according to the algorithm

How to prevent it?

Just now we said that the problem here is mainly that the client chooses to trust, so the main reason is that users should keep their eyes open and stay vigilant!