https packet capture principle

In one section, we analyzed the secure communication process of HTTPS and learned that HTTPS can effectively prevent man-in-the-middle attacks. But anyone who has used packet capture tools knows that Charles and Fiddler, for example, can capture HTTPS requests and decrypt them. How do they do this?

First, let’s look at the description of HTTPS proxy on Charles’ official website: (recommended learning: web front-end video tutorial)

Charles acts as an intermediary agent. When the browser communicates with the server, Charles receives the server's certificate, but dynamically generates a certificate and sends it to the browser. That is to say, Charles acts as an intermediary agent in the browser. Communicates with the server, so the communication data can be intercepted and decrypted by Charles. Since Charles has changed the certificate, the browser will give a security warning if the verification does not pass. You must install Charles' certificate before normal access can be performed.

What Charles needs to do is to disguise the server to the client and the client to the server:

Intercept the HTTPS request of the real client and disguise the client The client sends an HTTPS request to the real server

Accepts the real server response, and uses Charles' own certificate to disguise the server to send the data content to the real client

Let's look at the specific process:

The client initiates an HTTPS request to the server

Charles intercepts the client's request and pretends to be a client to make a request to the server

The server sends a request to the "client" (actual The above is Charles) Returning the server's CA certificate

Charles intercepts the server's response, obtains the server certificate public key, then makes a certificate himself, replaces the server certificate and sends it to the client. (In this step, Charles gets the public key of the server certificate)

After the client receives the certificate of the "server" (actually Charles), it generates a symmetric key, encrypts it with Charles' public key, and sends it Give the "server" (Charles)

Charles intercepts the client's response, decrypts the symmetric key with his own private key, then encrypts it with the server certificate public key and sends it to the server. (In this step, Charles gets the symmetric key)

The server decrypts the symmetric key with its own private key and sends a response to the "client" (Charles)

Charles intercepts the server's response, Replace it with your own certificate and send it to the client

At this point, the connection is established. Charles has obtained the public key of the server certificate and the symmetric key negotiated between the client and the server. Afterwards, he can decrypt or modify the encrypted message. .

The principle of HTTPS packet capture is quite simple. To put it simply, Charles, as a "middleman agent", gets the public key of the server certificate and the symmetric key of the HTTPS connection. The premise is that the client chooses Trust and install Charles' CA certificate, otherwise the client will "alarm" and terminate the connection. From this point of view, HTTPS is still very safe

The above is the detailed content of https packet capture principle. For more information, please follow other related articles on the PHP Chinese website!