Why cannot Wireshark decrypt HTTPS data?

Why cannot Wireshark decrypt HTTPS data?
GuideTo locate a problem, tcpdump captures https data packets on the server and downloads the packets to the local machine to enable wireshark analysis. Then we downloaded the private key configuration for the domain name to wireshark and found that the data packets could not be decrypted. Is it wireshark's method of configuring the key? However, many articles on Google say this configuration. I don't know much about HTTPS at the moment. No way. I had to understand the tls Protocol first. So I checked the RFC document of TLS1.2 and finally barely answered this question.TLS handshake

Before solving this problem, let's take a look at the entire TLS handshake process. The uncommon process is omitted.

The following describes the handshaking steps in sequence.

Client Hello

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

Server Hello

After receiving the Client Hello packet from the Client, the server selects an cipher suite based on the list of cipher suites sent by the Client and generates a random string to return to the Client. We can see that the cipher suite in is, the key exchange algorithm uses ECDHE_RSA, And the symmetric encryption algorithm uses AES_256_GCM_SHA384,

Server Certificate

The Server Key Exchange Protocol package is returned by the Server. It is mainly used to Exchange keys for symmetric Data Encryption with clients.

Server Hello Done

The server returns the protocol data, indicating that the client has finished returning the data required for 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 sends it to the server to generate the final pre-master-secret.

Change Cipher Spec

This protocol is used to notify the client and server to complete the key exchange process and switch to symmetric encryption.
The TLS handshake process ends. To solve this problem, you also need to understand the key exchange algorithms, RSA and Diffie-Hellman.

Key Exchange Algorithm

Key Exchange algorithms are commonly used, including RSA and Diffie-Hellman.
The RSA algorithm is used for key exchange. The pre-master-secret is generated by the client and transmitted to the server using public key encryption.
For Key Exchange, the Diffie-Hellman algorithm is used. The pre-master-secret calculates the pre-master-secret by the information exchanged in the Key Exchange stage. Therefore, if the pre-master-secret is not stored on the hard disk or transmitted over the network, wireshark cannot obtain the session key and decrypt application data. Can we calculate the pre-master-secret in reverse order? Theoretically, but very difficult.
For more information about Diffie-Hellman algorithms, see https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange.

Solution

After talking about this, is there any way for wireshark to decrypt data? We can use the following methods to enable wireshark to decrypt https packets.
1. Man-in-the-middle attack;
2. Set the web server to use RSA as the exchange key algorithm;
3. If chrome and firefox are used, you can set and export the pre-master-secret log, and then set the pre-master-secret log Path in wireshark to decrypt the log.

Address: https://www.centos.bz/2015/12/why-wireshark-can-not-decrypt-https-data/

Reprinted address: http://www.linuxprobe.com/linux-wireshark-https.html ghost