Introduction
If you work with networks or infrastructure, you will often have opportunities to analyze traffic with packet captures using Wireshark. HTTPS traffic encrypted with TLS 1.3 is particularly harder to analyze than before, so it’s important to understand how to decrypt it. This article explains, step by step and in an easy-to-follow way, how to decrypt TLS 1.3 traffic using Wireshark — please use it as a reference.
Capturing HTTPS traffic with Wireshark
Inspecting encrypted traffic
Let’s take a look at how traffic encrypted with TLS appears in practice. Start Wireshark and begin a packet capture, then access any website from your browser. As an example below, I show the capture result when accessing one of Website from Google Chrome on my PC.
To display only traffic with a particular website, I applied this filter:
ip.addr == XX.XX.XX.XX
Looking at the capture, most packets are shown as “Application Data,” indicating their contents are encrypted. In other words, with TLS you cannot read the raw request/response contents directly.
Obtaining the key material needed for decryption
To decrypt TLS 1.3 traffic in Wireshark you need the session keys (ephemeral keys) exchanged between the client and server. TLS 1.3 uses new keys for each session and discards them afterward. This design ensures that even if a server’s private key is leaked, past communications remain confidential. This property is called perfect forward secrecy (PFS).
Below are the steps to obtain the session key material required for decryption. First, open PowerShell and set an environment variable temporarily, then run Chrome from that PowerShell session.
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:\Users\username> $env:SSLKEYLOGFILE = "$env:USERPROFILE\Desktop\sslkeys.log"
PS C:\Users\username> & "C:\Program Files\Google\Chrome\Application\chrome.exe"Next, start a packet capture in Wireshark and access a website from the browser. A file named sslkeys.log will be output to the path you specified above.
Now let’s look inside sslkeys.log. You’ll see many lines of key material like the example below. By loading these keys into Wireshark, you can decrypt the traffic.
sslkey.log
—————————————————————————
CLIENT_HANDSHAKE_TRAFFIC_SECRET c48725e85c80e440ab4fdee7127baecada2fb879a49f754c95553bfd564efa55 f41cd91ed0989c931cd76ca4394b4b27f8a9b8b70ad276b3602c49c9f7fd8751
SERVER_HANDSHAKE_TRAFFIC_SECRET c48725e85c80e440ab4fdee7127baecada2fb879a49f754c95553bfd564efa55 63e872609deeccc889fa09ad9ebd49338a86fffa34b239b63fd0264a4357f2d3
CLIENT_TRAFFIC_SECRET_0 c48725e85c80e440ab4fdee7127baecada2fb879a49f754c95553bfd564efa55 9bed430f2121fc594512c8d0b0b32ec10f5c8981c49d72583b82db9e23e9be6d
SERVER_TRAFFIC_SECRET_0 c48725e85c80e440ab4fdee7127baecada2fb879a49f754c95553bfd564efa55 ee98d666042d28dc377ed7dd91586bd249fc60b9c58cbd46ce670a2c98516c85
EXPORTER_SECRET c48725e85c80e440ab4fdee7127baecada2fb879a49f754c95553bfd564efa55 83ff4aab48ea6af43244d1b96012cbd4cb997f8702f86fa4892840a12d5364b8Definitions:
- SERVER_TRAFFIC_SECRET_0
Key used to encrypt application data (e.g., HTTP responses) the server sends after the handshake completes.
Note: When re-keying occurs, this updates toSERVER_TRAFFIC_SECRET_1,_2, …
- CLIENT_HANDSHAKE_TRAFFIC_SECRET
Key used to encrypt data the client sends during the handshake.
- SERVER_HANDSHAKE_TRAFFIC_SECRET
Key used to encrypt data the server sends during the handshake.
- CLIENT_TRAFFIC_SECRET_0
Key used to encrypt application data (e.g., HTTP requests) the client sends after the handshake completes.
Note: When re-keying occurs, this updates toCLIENT_TRAFFIC_SECRET_1,_2, …
How to verify decrypted traffic
Now point Wireshark to the session key file.
Open “Edit” → “Preferences.”

Expand “Protocol.”

Select “TLS.”
For “(Pre)-Master-Secret log filename” specify the session key file. Click “Browse” and select the session key file you previously exported.

Once the file is specified, click “Apply.”

That’s it — configuration is complete. Finally, check whether decryption worked.

Previously the Length/Info column showed “Application Data” because the contents were encrypted. Now you should see something like:
GET /quiz/public HTTP/1.1
confirming that the GET request is visible.
Conclusion
That concludes the explanation of decrypting TLS traffic with Wireshark. Because TLS 1.3 encrypts portions of the handshake, you may encounter more situations where decrypting traffic is necessary to analyze communication errors. Learn and practice Wireshark troubleshooting in advance so you won’t be caught off guard.


コメント