Two ways to decrypt HTTPS traffic with Wireshark

principle

Let's review the entire handshake process of SSL/TLS:

(1) Clienthello: Sends the client's capabilities and preferences to the server. It is sent after the connection is established, when renegotiation is desired, or in response to a server's renegotiation request.

(2) version: the best protocol version supported by the client

(3) Random: 32 bytes in total, 28 bytes of random numbers, 4 bytes of additional information, affected by the client clock (to avoid browser fingerprinting, the 4-byte clock is generally distorted)

(4) Session ID: A 32-byte random number used to reestablish a session with the server. If it is empty, it means a new session is created.

(5) cipher suit: all cipher suites supported by the client, arranged in order of priority

(6) Compression: Compression algorithm supported by the client. No compression is the default.

(7) Extensions: Consists of any number of extensions, carrying additional data

(8) ServerHello:

• Select the parameters provided by the client and feed them back to the client
• The server does not need to support the best version supported by the client. If the server does not support the client version, it can provide other versions in the hope that the client can accept it.

(9) Certificate:

• Used to carry the server X.509 certificate chain
• The primary certificate must be sent first, with the intermediate certificates following in the correct order.
• The server must ensure that the certificate sent is consistent with the selected algorithm suite
• Certificate message is optional

(10) ServerKeyExchange: Carries additional data for key exchange, depending on the encryption suite

(11) ServerHelloDone: The server has sent all expected handshake messages.

(12) ClientkeyExchange: carries the information provided by the client for key exchange

(13) ChangeCipherSpec: The sender has obtained enough information for the connection parameters.

(14) Finish: The handshake is complete, the message content is encrypted, and both parties can exchange verification and the data required for the integrity of the entire handshake

(15) Algorithm: verrify_data = PRF(master_secret, finished_label,hash(handshake_message))

To decrypt HTTPS traffic, you need to get the encryption key, which is generated by the master key, the client random number, and the server random number. From the above handshake process, we can see that the client random number and the server random number are transmitted in the handshake message between the two parties, and the master key (master_secret) is generated by the pre-master key (pre_master_secret) combined with the two random numbers. The pre-master key is exchanged through the key exchange algorithm in the cipher suite (DH, RSA).

Therefore, to decrypt HTTPS with Wireshark, you can start from two places:

• Select RSA as the key exchange algorithm, then extract the server's private key and import the private key into Wireshark. Use Wireshark to decrypt the pre-master key transmitted during the key exchange process, and then generate the master key by combining the previous client and server random numbers. Further generate the encryption key, and then you can decrypt the encrypted messages captured later.
• Extract the master key directly from the client, combine the client and server random numbers to generate the encryption key, and decrypt the encrypted message.

The following demonstrates two methods for decrypting HTTPS traffic.

Method 1

Export the P12 certificate with the private key from the server, or directly export the server's private key.

Capture the complete message starting from the TCP three-way handshake:

It can be seen that the message at this time is encrypted by TLS and the specific message content cannot be seen.

Click Edit -> Preferences -> Protocols -> SSL (some versions only have TLS), and import the RSA key:

Since the keys exchanged via the DH method are not passed in the middle, this method can only decrypt keys exchanged via RSA.

Import the server certificate:

After clicking OK, Wireshark will decrypt the captured message:

The message is successfully decrypted, and the request and response of the HTTP message can be intuitively seen.

The second

By setting environment variables, the master_secret of the browser can be intercepted to achieve the purpose of decrypting HTTPS.

Create a new user variable SSLKEYLOGFILE=path\sslkey.log file in the environment variable, and then specify the file location in the ssl configuration in wireshark.

Click Edit > Preferences > Protocol > SSL:

You can decrypt the browser's access traffic: