Let’s review the entire handshake process for SSL/TLS:

  • Clienthello: Sends the client’s functions and preferences to the server. After the connection is established, it will be sent when you want to renegotiate or respond to the server’s renegotiation request.
    • Version: the best protocol version supported by the client
    • Random: A total of 32 bytes, 28 bytes of random number, 4 bytes of extra information, affected by the client clock (to avoid browser fingerprint acquisition, now generally will be distorted by the 4-byte clock)
    • Session ID: 32-byte random number, used to reestablish the session with the server, empty to indicate a new session
    • Cipher suit: all cipher suites supported by the client, prioritized
    • Compression: compression algorithm supported by the client. The default is no compression.
    • Extensions: consists of any number of extensions, carrying extra data
  • ServerHello:
    • Select the parameter feedback client provided by 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, other versions can be provided to expect the client to accept
  • Certificate:
    • Used to carry the server X.509 certificate chain
    • The primary certificate must be sent first, and the intermediate certificate follows the primary certificate in the correct order.
    • The server must ensure that the certificate sent is consistent with the selected algorithm suite
    • Certificate message optional
  • ServerKeyExchange: Extra data carrying key exchange, depending on the cipher suite
  • ServerHelloDone: The server has sent all expected handshake messages.
  • ClientkeyExchange: carries the information provided by the client for key exchange
  • ChangeCipherSpec: The sender has obtained enough information to connect the parameters.
  • Finish: The handshake is completed, the message content is encrypted, and both parties can exchange the verification and the data required for the integrity of the entire handshake.
    • Algorithm: verrify_data = PRF(master_secret , finished_label, hash(handshake_message))

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

Therefore, by Wireshark decrypting HTTPS, you can start from two places: 1. The key exchange algorithm selects RSA, then extracts the private key of the server, imports the private key into Wireshark, and decrypts the pre-master key passed during the key exchange process through Wireshark. Then, the master key is generated by combining the previous client and server random numbers, and the encryption key is further generated, so that the encrypted packets that are subsequently captured can be decrypted. 2. The pre-master key is directly extracted from the client, and the encryption key is generated by combining the client and the server random number to decrypt the encrypted message.

The following demonstrates two ways to decrypt HTTPS traffic.

method one

Export the certificate in P12 format with the private key from the server, or directly export the private key of the server.

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



You can see that the packet at this time is encrypted by TLS and cannot see the specific packet content.

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


Since the keys exchanged by the DH method are not passed in the middle, this method can only decrypt the keys exchanged through the 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 visually seen.



The purpose of decrypting HTTPS is achieved by setting the environment variable to intercept the browser’s pre_master_secret.

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


Click Edit > Preferences > Protocol > ssl:


You can decrypt your browser’s access traffic:



Orignal link: