In modern networking, securing data transmission is paramount, and Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are widely used protocols to ensure data privacy and security. However, there are instances where you might need to analyze encrypted traffic for troubleshooting, forensic analysis, or network monitoring. This technical article will guide you through decrypting SSL/TLS traffic using Wireshark and tcpdump, two powerful network analysis tools. We will cover what Wireshark and tcpdump are, explain SSL and TLS encryption, and demonstrate how to decrypt SSL traffic using a pre-master secret key or an RSA private key.

What are Wireshark and tcpdump? #

Wireshark #

Wireshark is an open-source network protocol analyzer that enables users to capture and interactively browse the traffic running on a computer network. It allows you to inspect data at a granular level, providing visibility into the protocols and data packets being transmitted. Wireshark is widely used for network troubleshooting, protocol development, and security analysis.

tcpdump #

tcpdump is a command-line packet analyzer tool that captures network traffic and displays it in real-time. It is highly efficient for capturing data from live networks, allowing you to save packets to a file (known as a capture file) for later analysis. While tcpdump lacks the graphical interface of Wireshark, it is powerful for quick analysis, filtering packets, and collecting data on remote systems.

What is SSL Encryption? #

SSL (Secure Sockets Layer) is a protocol developed by Netscape for transmitting private documents via the Internet. SSL uses encryption algorithms to ensure that data sent between the client (e.g., a web browser) and the server is unreadable to anyone who intercepts the transmission.

TLS (Transport Layer Security) is the successor to SSL and is more secure. While TLS is technically distinct from SSL, the term SSL is often used to refer to both protocols.

SSL/TLS operates by establishing a secure communication channel between two systems. The key concepts in SSL/TLS encryption include:

• Symmetric Encryption: A single key is used to encrypt and decrypt the data.
• Asymmetric Encryption: Two keys (public and private) are used; data encrypted with the public key can only be decrypted with the corresponding private key.
• Certificates: SSL/TLS uses certificates to verify the identity of the server and sometimes the client.
• Handshake: The process where the client and server establish a secure connection, exchanging keys, and agreeing on encryption methods.

Decrypting SSL with a Pre-Master Secret Key #

The pre-master secret key is a crucial component in the SSL/TLS handshake process. This key is used to generate session keys, which are then used to encrypt the actual data transferred over the network. By obtaining the pre-master secret key, you can decrypt the session data.

Basic Steps to Decrypt SSL with a Pre-Master Secret Key #

To decrypt SSL traffic using the pre-master secret key, follow these steps:

1. Set the Log File Environment Variable
2. Capture with tcpdump and Verify the Log File
3. Configure Wireshark for SSL Decryption

Set the Log File Environment Variable #

Setting SSLKEYLOGFILE on Windows #

On Windows systems, you’ll need to set an environment variable to store the pre-master secret keys in a log file. This variable, named SSLKEYLOGFILE, defines the path where these keys are saved.

1. Start by right-clicking on My Computer and selecting Properties from the menu to open the System menu.
2. Click on Advanced system settings in the left-hand list to open the System Properties window.
3. In the Advanced tab, click the “Environment Variables” button.
4. Under User variables, click the New… button. You can also create this variable under System variables if you want to log SSL keys for all users on the system. However, it’s usually best to keep it confined to your profile.
5. In the Variable name field, enter SSLKEYLOGFILE.
In the Variable value field, enter the path where you want to save the log file. Alternatively, you can click Browse file… to select the path using the file picker.
If you’re setting this as a system-wide variable, make sure the file is accessible to all users, or use wildcards. For example, you could use %USERPROFILE%\AppData\ssl-keys.log or C:\ssl-keys.log .
6. Once you’re done, click OK to apply the changes and proceed with the next steps.

Setting SSLKEYLOGFILE on Linux or Mac #

On Linux and Mac, you’ll need to set the SSLKEYLOGFILE environment variable using export. In the same terminal, you can execute tcpdump and it will generate the indicated key log file when a SSL connection is detected.

root@noid-01:~# export SSLKEYLOGFILE=~/.ssl-key.log
root@noid-01:~# tcpdump ...

To maintain a permanent environment variable configuration, edit the user profile with a text editor like nano. For Linux, this variable is stored in ~/.bashrc, and on Mac, it is created in ~/.bash_profile. Then, add the export command for SSLKEYLOGFILE variable at the end of the file and save the changes.

Capture with tcpdump and Verify the Log File #

To test the log file generation, try to open a browser, tcpdump or launch a curl command to an HTTPS server to confirm that the file is properly generated.

As an example, in the same terminal where the environment variable were created, the tcpdump to capture the traffic and a curl to a HTTPS service will be launched to be decrypted:

root@noid-01:~# export SSLKEYLOGFILE=~/.ssl-key.log
root@noid-01:~# tcpdump -i any port 443 -w ~/capture.pcap &
root@noid-01:~# curl https://
(then, close the tcpdump command)

Verify that the log file ~/.ssl-key.log and the traffic capture at ~/capture.pcap are generated. Finally, see the last step to see the encrypted traffic with wireshark.

If you open the ssl-key.log file you’ll see something like the following:

root@noid-01:~# cat ~/.ssl-key.log
CLIENT_HANDSHAKE_TRAFFIC_SECRET 83ac6b24496f208daee39dfdfcbd36b7c428245af5e3775e42099dbd48741d4a db6f3d27b40b7c8e10ed415281b39e45ca6ef2b59468f943dbe6e81e1f82e0f0
SERVER_HANDSHAKE_TRAFFIC_SECRET 83ac6b24496f208daee39dfdfcbd36b7c428245af5e3775e42099dbd48741d4a d819660e194d9439e7152ceac2a439b41584afbeb5d719663cecb3c63b5c2eb1
CLIENT_TRAFFIC_SECRET_0 83ac6b24496f208daee39dfdfcbd36b7c428245af5e3775e42099dbd48741d4a 71d4806141cb1b247c1d1f3f7747a804fcc5e06c4192d8f53fc763a27b92316c
SERVER_TRAFFIC_SECRET_0 83ac6b24496f208daee39dfdfcbd36b7c428245af5e3775e42099dbd48741d4a 2ca17b0f7ff708fb3001be17a1c85163219221a4595462415e9e9e6653daf1fa
EXPORTER_SECRET 83ac6b24496f208daee39dfdfcbd36b7c428245af5e3775e42099dbd48741d4a 3f74b0cbe802d3e3dd3b5f6dee4114f928ec936a0cd388643d146cfb606f62a4

Configure Wireshark for SSL Decryption #

Once the capture system is logging pre-master keys, you can use the key log file along with the captured packets to decrypt SSL traffic in Wireshark.

1. Upload the key log and capture files into the system where Wireshark is installed.
2. Open the traffic capture file with Wireshark.
3. Configure the SSL Protocol. Click on Edit, then select Preferences. The Preferences dialog will open, showing a list of items on the left. Expand the Protocols section, scroll down, and click on SSL. In the SSL protocol options, locate the field labeled (Pre)-Master-Secret log filename. Browse to the log file you set up earlier, or paste the path directly into this field.
4. Apply the Configuration. After setting the (Pre)-Master-Secret log filename, click OK to save your changes and return to Wireshark. You’re now ready to decrypt the captured traffic. When you select an encrypted data frame, check the Packet byte view. Underneath the view, you should see a tab for Decrypted SSL data among others.

If the session data still appears unreadable and you can’t see any HTML, it might be due to GZIP compression, which is commonly used by web servers like Apache. In this case, click the Uncompressed entity body tab, which is only available when SSL decryption is enabled. Here, you can view the uncompressed source code of the site, such as the title element of the default Apache page in plaintext.

Using an RSA key to decrypt SSL #

Wireshark offers a feature that allows you to upload your RSA keys for decrypting SSL traffic, but in practice, RSA key decryption has become outdated.

This decline in usage is due to the adoption of Perfect Forward Secrecy (PFS), which has rendered traditional RSA key decryption obsolete. With PFS, sessions negotiated using Diffie-Hellman don’t rely on the RSA key directly. Instead, they generate a one-time key that is stored only in RAM and encrypted using the key on disk.

If you previously used an RSA key to decrypt traffic and found it no longer works, the target machine is likely using Diffie-Hellman key exchanges. You can confirm this by enabling SSL logging in Wireshark.

To enable logging:

1. Click on Edit in the toolbar menu and select Preferences.
2. Expand the Protocols section on the left, scroll down, and click on SSL.
3. Set the location for your SSL log file by clicking the Browse button.

Once logging is enabled, capture a session with your SSL-enabled host and check the logs. Look for the TLS handshake negotiation frame; you’ll likely see a DHE (or ECDHE, for elliptic-curve keys) entry in the cipher string, indicating that Diffie-Hellman key exchanges are in use.

If you see a message indicating that the master secret cannot be found, and RSA key decryption fails, you’ll need to switch to the pre-master secret method for decryption.

As PFS becomes more widespread, especially with the advent of TLS 1.3, traditional RSA key decryption is deprecated and should no longer be relied upon.

Know more #

The SSLKEYLOGFILE Format for TLS #

The SSLKEYLOGFILE format is a text file used to store pre-master secret keys for decrypting TLS connections. The file is encoded in UTF-8, with each line containing a secret identified by a label, a client random value, and the secret itself, all separated by spaces. The format accepts various line endings (CRLF, CR, LF), and lines starting with # are treated as comments.

For TLS 1.3, several labels correspond to different stages of the key schedule, such as CLIENT_HANDSHAKE_TRAFFIC_SECRET and SERVER_TRAFFIC_SECRET_0. For TLS 1.2 and earlier, the CLIENT_RANDOM label identifies the master secret.

Security Considerations:
Access to the SSLKEYLOGFILE allows decryption of TLS traffic, posing a significant security risk. Proper access controls are essential to prevent unauthorized access or privilege escalation. Logging should only be enabled by authorized users, and strict file permissions should be applied. The logged secrets not only allow decryption but can also enable attackers to modify or inject data into active connections, and in some cases, impersonate endpoints or forge messages.

How Does a Two-Way SSL Handshake Work? #

A two-way SSL handshake authenticates both the server and the client. Here’s how the process unfolds:

1. Client Hello: The client initiates the handshake by sending a “Client Hello” message to the server. This message includes the client’s supported cipher suites and TLS version compatibilities.
2. Server Hello: The server responds with a “Server Hello” message, which contains the server’s public certificate and a request for the client’s certificate.
3. Client Certificate Validation: The client verifies the server’s certificate. If it’s valid, the client sends its own certificate back to the server.
4. Server Certificate Validation: The server checks the client’s certificate. If the client’s certificate is valid, the session establishment proceeds, allowing secure communication between both parties.

Is It Possible to Decrypt Passively Sniffed SSL/TLS Traffic? #

Yes, it is possible to decrypt passively sniffed SSL/TLS traffic, but you will need the RSA key to do so. This key can be obtained through legitimate means with proper authorization or, less ethically, by intercepting it using a “man-in-the-middle” attack.