How to Decrypt TLS/HTTPS Traffic Automatically

Trace Eagle lets you decrypt HTTPS automatically: captured TLS traffic is ciphertext by default, and Trace Eagle matches each session key to its connection by the TLS client_random, so traffic decrypts the moment it’s captured and the plaintext requests and responses appear right next to the raw bytes. Browsers, Electron apps and common HTTP(S) clients decrypt out of the box; apps with certificate pinning or in-house encryption need one extra step. The key condition: start capturing before the connection is established.

How does the decryption work?

Trace Eagle keeps “capturing raw bytes” and “obtaining TLS keys” separate, then joins them automatically by the TLS client_random. That means no exporting a key file as with SSLKEYLOGFILE, and no pairing keys to connections by hand.

Key derivation follows the protocol version: TLS 1.3 uses HKDF-Expand-Label (see RFC 8446), and TLS 1.2 uses the master secret + PRF (see RFC 5246). Cipher suites are detected automatically, covering AES-128/256-GCM, ChaCha20-Poly1305 and AES-CBC.

What traffic decrypts automatically?

• Browsers, Electron apps, and common HTTP(S) clients: decrypt out of the box, captured as plaintext.
• TLS 1.2 and TLS 1.3, HTTP/1.1, HTTP/2, and HTTP/3 (QUIC) are all within the coverage.

When do you need one extra step?

• Apps with certificate pinning, or running in-house encryption: ordinary proxies are turned away. Switch to App-layer plaintext capture to read plaintext directly from inside the program, where pinning is no obstacle; or, if you want to stay on the proxy, bypass SSL pinning first.
• When you need to decrypt via a proxy: install a capture certificate on the target once, see how to install the capture certificate. Most capture methods (direct NIC capture, targeting a specific program, app-layer plaintext capture) need no certificate at all.

What can’t be decrypted for now

A few programs expose no way to obtain their keys. For these, the per-packet / raw view can still show the encrypted traffic itself; you simply can’t see the plaintext yet. The app labels how far it can get for each specific program, so you don’t have to guess.

Why won’t my HTTPS traffic decrypt?

1. Did you start capturing early enough? Keys are obtained when the connection is established, so you must start capturing before the traffic happens; a connection already underway when you started capturing may not be decryptable.
2. Is the certificate installed (when decrypting via a proxy)? Confirm the capture certificate is trusted on the target, see Certificate management and installation.
3. Is it certificate pinning? If it still errors out and won’t decrypt even with the certificate installed, pinning is the likely cause; switch to App-layer plaintext capture.
4. Still no luck? See the FAQ.

FAQ

Do I have to install a certificate to decrypt HTTPS?

Not usually. A capture certificate is needed only when decrypting through proxy capture; NIC capture, per-program capture and app-layer plaintext capture don’t need one.

Is TLS 1.3 supported?

Yes. Both TLS 1.3 and TLS 1.2 decrypt: the former via HKDF-Expand-Label, the latter via the master secret + PRF, with cipher suites detected automatically.

Why do some connections from the same program decrypt and others don’t?

Most often the capture started too late: keys are obtained when a connection is established, so connections opened before capture began may not decrypt. Re-establish the connection (for example, restart the target program) and check again.

Can I still see traffic that can’t be decrypted?

Yes. The per-packet and raw views still show the encrypted traffic itself, just not the plaintext, and the app labels how far it can get for that program.