Incident response

Network traffic analysis for Incident Response (IR): TLS decryption

Introduction to TLS

When the internet was being created, security wasn’t much of an issue. The internet (and the Arpanet before it) was primarily being used by trusted parties and hacking wasn’t really a thing yet. As a result, many of the protocols used today weren’t developed for security. Potentially sensitive data was sent in plaintext over the wire and no mechanism existed for authenticating the server to the client.

The Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are designed to fix this. They sit between a high-level protocol (like HTTP) and a low-level protocol (like TCP) in the network stack and provide the necessary encryption and authentication functionality.

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

Over the years, the use of TLS has grown dramatically, with over half of websites using HTTPS by default. However, situations exist where it is useful to be able to decrypt this traffic. For example, many organizations perform deep packet inspection (DPI) in order to detect and block potentially malicious traffic.

TLS decryption

When performing incident response activities, it may be necessary to decrypt TLS traffic in order to examine the contents of potentially malicious traffic. In this section, we’ll discuss how Wireshark and web proxies can be used to for TLS decryption.

Wireshark

Wireshark is probably the most commonly used tool for network traffic analysis. It has a great deal of functionality built in for examining network traffic and is freely available from the Wireshark website.

One of the useful features of Wireshark is built-in support for decryption of TLS traffic. Depending on the details of the SSL/TLS implementation, two different options exist for decryption.

RSA keys

In the past, it was common to use RSA to protect the confidentiality of the process of setting up a shared secret key between the client and the server. However, the nature of RSA means that anyone with access to an RSA private key can decrypt any TLS session that is protected with that key. The potential that the theft of a private key could allow decryption of cached network traffic has prompted a move to “ephemeral” key exchanges.

However, Wireshark still supports loading of an RSA key for TLS decryption. This can be accomplished by selecting Edit → Preferences and selecting TLS from the Protocols dropdown in the left-hand menu. This produces the screen above, where an RSA can be added using the button at the top (highlighted).

Once an RSA key has been added to Wireshark, it will decrypt any traffic protected by that RSA key.

Pre-master secret logs

If TLS traffic is protected using an ephemeral key exchange protocol, like Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE), then decryption requires access to the TLS Pre-Master Secret. Many browsers support printing these values while a browser is in use. This can be accomplished by setting the SSLKEYLOGFILE environment variable to point to the desired output file.

If the TLS pre-master secret is collected for a browsing session, it can be imported into Wireshark using a similar process as RSA keys. When the screen shown in the previous example is reached, use the Browse button near the bottom to select the appropriate file. Once again, Wireshark will automatically decrypt any TLS traffic for which a pre-master secret is available.

Web proxy

Decrypting traffic in Wireshark is useful for incident response but not as much for preventative actions. By the time that a sample is loaded in Wireshark, decrypted and analyzed, the opportunity has passed.

Using a web proxy like Burp Proxy, an organization can perform deep packet inspection in real-time. A web proxy works by performing a man-in-the-middle (MitM) attack against an organization’s own traffic. The proxy creates a secure channel between itself and the client, another one between itself and the client, and perform decryption, traffic analysis and encryption in the middle of each flow.

In order to be effective, a web proxy needs to be able to create a trusted HTTPS channel between itself and the client. Accomplishing this requires placing a root certificate owned by the organization on every machine in the business. This allows the organization to generate verifiable certificates for any website that the client may try to visit.

The main advantage of web proxies for TLS decryption is that it enables scalable, real-time deep packet inspection. The main disadvantage is that it breaks the TLS connection between the client and server, creating a single point of failure in the network and preventing the client from verifying the server’s certificate (since they only see the one owned by the proxy).

Applications of TLS decryption for incident response

The ability to decrypt TLS traffic is a valuable one for incident response. The purpose of TLS is to make it impossible to differentiate one type of traffic from another. Malware authors take advantage of this to hide their malicious traffic among legitimate traffic.

By enabling deep packet inspection, TLS decryption can be useful for identifying initial infection vectors and analyzing malware command and control traffic.

Initial infection vector analysis

Identification of the initial infection vector is an important component of incident response. Determining where the malware infection originated can help to determine if the infection is more widespread and to help block future infections.

Many attacks begin as phishing emails, which point users to malicious phishing websites. These websites serve the user malicious content which installs malware on the computer. This process is often carried out over HTTPS, making it invisible to analysts without the ability to perform TLS decryption for deep packet inspection.

Another application of TLS decryption for initial infection vector identification is ensuring that DNS whitelisting and blacklisting remains possible. Traditionally, DNS queries have been sent out in plaintext, making it possible to monitor for and block attempted resolutions of malicious domains. However, with DNS over HTTPS (DoH), DNS requests will be sent out encrypted as HTTPS requests. In order to maintain the visibility necessary to perform DNS blacklisting, analysts need to be able to decrypt TLS traffic to read the hidden domain requests.

Malware command-and-control analysis

Malware also commonly uses TLS to protect command-and-control (C2) communications. Network communications are a necessary component of most malware due to the need to communicate with the owner to receive commands or send stolen data. Network analysts take advantage of this by deploying security appliances at the bottleneck that all internal traffic passes through to reach the internet.

Malware command-and-control traffic is most stealthy when it closely resembles legitimate traffic. This has led to many malware variants embedding C2 traffic inside HTTP(S) requests and responses, since they are common and not blocked by firewalls. 

As HTTPS has become more popular, malware authors have adopted it both to blend in and take advantage of the ability to conceal their communications. Without TLS encryption, incident responders cannot take advantage of collected network traffic to determine the activities of malware on the network.

Conclusion: Performing TLS decryption

TLS decryption can be used for a variety of different purposes within cyberdefense and incident response. Tools like Wireshark and Burp Proxy can be used to perform TLS decryption; however, the effectiveness of each tool depends on the task for which it is being used. Wireshark is better for incident response and analysis, while web proxies are more effective for real-time deep packet inspection.

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

 

Sources

1. Majority of the world’s top million websites now use HTTPS, We Live Security
2. Wireshark, wireshark.org
3. The Burp Suite family, PortSwigger