Wireshark cannot decrypt HTTPS data solution

Introduced

The function of the network packet analysis software can be imagined as "electrician technicians use electric meters to measure current, voltage, resistance"-just porting the scene to the network and replacing the wire with the network cable. In the past, the network packet analysis software is very expensive, or specifically belongs to the use of the software business. Ethereal's appearance changed all this. Under the scope of the GNUGPL general license, users can obtain the software and its source code at no cost, and have the right to modify the source code and custom. Ethereal is one of the most widely used network packet analysis software in the world at present.

Wireshark cannot decrypt HTTPS data solution

Problem

Because you need to locate a problem, tcpdump the HTTPS packet on the server, and then download it 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 Wireshark the wrong way to configure the key? But Google has a lot of articles are said this configuration. Due to the lack of understanding of HTTPS, I do not know how to solve. No way, can only understand the TLS this protocol, so look at the TLS1.2 RFC document, finally reluctantly answered this doubt.
TLS handshake Whole process

Before solving this problem, take a holistic look at the whole process of TLS handshake. The uncommon process is omitted. As shown in figure:

The following sequence describes the handshake steps.

Client Hello

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

Server Hello

After the server receives client Hello packets from clients, select an encryption suite based on the list of cryptographic packages sent by the client, and generate a random string to return to the client. We see the encryption suite in the figure below, where the key exchange algorithm uses ECDHE_RSA, and the symmetric encryption algorithm uses aes_256_gcm_sha384, as shown in the figure:

Server Certificate

The server then returns a list of certificates, including certificate chains and domain name certificates. The returned certificate is used to authenticate the client to the current connection server and to prevent man-in-the-middle attacks.

Server Key Exchange

The Server key exchange protocol package, which is returned by the servers, primarily to exchange keys for data symmetric encryption with clients. As shown in figure:

Server Hello Done

The server returns this protocol data telling the client that it has completed 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. As shown in figure:

Change Cipher Spec

This protocol is used to communicate with the client and the server to complete the key exchange process, you can switch to the symmetric encryption process.

The approximate TLS handshake is over here. To solve the problem in this article, we also need to understand the key exchange algorithm, RSA and Diffie