How to Capture and Decrypt HTTPS Traffic with Wireshark and SSLKEYLOGFILE

A reader wanted to capture packets from baidu.com but couldn’t see any data. First, the IP address was obtained with ping baidu.com:

$ ping baidu.com
PING baidu.com (39.156.66.10): 56 data bytes
64 bytes from 39.156.66.10: icmp_seq=1 ttl=49 time=30.6 ms
...

Using the IP, the traffic was captured with tcpdump:

$ tcpdump -i eth0 host 39.156.66.10 -w baidu.pcap

The resulting baidu.pcap file was opened in Wireshark and filtered with http.host == "baidu.com", but no packets were found because the connection uses HTTPS, which encrypts the HTTP host and request body.

Why the packets are invisible

HTTPS encrypts the HTTP layer, so filtering by http.host cannot match encrypted traffic. However, the TLS handshake contains a server_name extension that reveals the intended hostname. Filtering with the following expression captures the packets:

tls.handshake.extensions_server_name == "baidu.com"

After selecting a packet and choosing Follow → TCP Stream , the encrypted data becomes visible.

Decrypting the HTTPS traffic

To decrypt, first capture the traffic again:

$ tcpdump -i eth0 host 39.156.66.10 -w baidu.pcap

Then export the TLS master secrets by setting the environment variable SSLKEYLOGFILE before invoking a client that supports it (e.g., curl or Chrome):

$ export SSLKEYLOGFILE=/Users/xiaobaidebug/ssl.key
$ curl 'https://baidu.com'
# or on macOS
$ open -a Google\ Chrome https://baidu.com

The file /Users/xiaobaidebug/ssl.key is created. In Wireshark, open Edit → Preferences → Protocols → TLS and set the "(Pre)-Master-Secret log filename" to the path of ssl.key. After applying the change, the previously encrypted packets (e.g., packet 18 and 20) are decrypted.

HTTPS handshake overview

HTTPS uses TLS 1.2 (or later) and consists of two phases:

Phase 1 – TLS handshake (asymmetric encryption) : client and server exchange random values and the pre‑master secret, then derive a session key.

Phase 2 – Encrypted data transfer (symmetric encryption) : all subsequent traffic is encrypted with the session key.

The four handshake messages are: Client Hello: client advertises supported TLS versions, cipher suites, and sends a client random . Server Hello: server returns a server random , its certificate, and selects the protocol version. Client Key Exchange: client generates a pre_master_key , encrypts it with the server’s public key, and sends it. Change Cipher Spec and Finished: both sides confirm the handshake and start using the derived session key.

Extracting the pre‑master key

The ssl.key file contains lines of the form:

CLIENT_RANDOM 5709aef8ba36a8eeac72bd6f970a74f7533172c52be41b200ca9b91354bd662b 09d156a5e6c0d246549f6265e73bda72f0d6ee81032eaaa0bac9bea362090800174e0effc93b93c2ffa50cd8a715b0f0

Each line has three columns: the literal CLIENT_RANDOM, the client random , and the corresponding pre_master_key . Wireshark extracts the client random from the captured Client Hello packet, matches it to the second column, and then uses the third column to compute the session key for decryption.

Summary

Simple packet capture of HTTPS sites shows no data because the HTTP layer is encrypted.

Filtering by TLS server_name can locate the handshake packets.

Setting SSLKEYLOGFILE before running a TLS‑enabled client exports the necessary secrets.

Configuring Wireshark with the exported key file allows decryption of the captured traffic.

The three critical values are client random , server random (both plaintext) and the encrypted pre_master_key obtained from the key log.

References

GeekTime – "Network Troubleshooting Cases" course.