Why Wireshark cannot decrypt HTTPS data

Why Wireshark cannot decrypt HTTPS data

Guide

Because of the need to locate an issue, tcpdump crawls HTTPS packets on the server and then downloads to the local open Wireshark analysis. Then we download the domain name private key configuration to Wireshark, found that the packet can not be decrypted. Is the Wireshark method of configuring the key incorrect? But Google has a lot of articles are said to be configured in this way. Because the understanding of HTTPS is not deep enough, at a moment do not know how to solve. No way, only to understand the TLS protocol, and then look at the TLS1.2 RFC document, and finally reluctantly answered this doubt.

TLS handshake entire process

Before solving this problem, let's look at the whole process of TLS handshake. The uncommon process is omitted.

Each handshake step is described in the following order.

Client Hello

This is the first step of the TLS handshake, and the client initiates the request. This protocol mainly includes a random string generated by the client (used to generate session key below), as well as a list of cryptographic suites supported by the client.

Server Hello

After the server receives the client's Hello packet, a cryptographic suite is selected based on the client's list of cryptographic suites, and a random string is generated to return to the client. We see in the cipher suite that the key exchange algorithm uses ECDHE_RSA, the symmetric encryption algorithm uses aes_256_gcm_sha384,

Server Certificate

Server key exchange protocol package, returned by the server, is primarily intended to exchange keys with the client for symmetric encryption of data.

Server Hello Done

The server returns this protocol data, telling the client that it has finished returning the data needed for the key exchange. The server waits for the client to respond.

Client Key Exchange

The client generates DH public data based on the DH key data returned by the server and is sent to the server to generate the final pre-master-secret.

Change Cipher Spec

This protocol is used by the client and the server to communicate with each other and also complete the key exchange process, which can be switched to the symmetric encryption process.
Here the approximate TLS handshake is over. To solve the problems in this article, we also need to understand the key exchange algorithms, RSA and Diffie–hellman.

Key Exchange Algorithm

The key exchange algorithm is commonly used in RSA and Diffie-hellman.
For key exchange using the RSA algorithm, Pre-master-secret is generated by the client and transmitted to the server using public key cryptography.
For key exchange using the Diffie-hellman algorithm, Pre-master-secret calculates the pre-master-secret by each of the information exchanged during the key exchange phase. So the Pre-master-secret does not save to the hard disk, also does not transmit on the network, Wireshark cannot obtain session key, also cannot decrypt the application data. Can we calculate the Pre-master-secret in reverse? Theoretically possible, but very difficult.
Interested in the Diffie-hellman algorithm can be referenced Https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Workaround

Having said so much, what is the way to let Wireshark decrypt the data? There are several ways to enable Wireshark to decrypt HTTPS packets.
1. Man-in-the-middle attack;
2. Set up the Web server to use RSA as the Exchange key algorithm;
3. If you are using Chrome,firefox, you can set the export Pre-master-secret log, and then Wireshark set the Pre-master-secret log path so that it can be decrypted.

Free to provide the latest Linux technology tutorials Books, for open-source technology enthusiasts to do more and better: http://www.linuxprobe.com/

Why Wireshark cannot decrypt HTTPS data