Decrypt HTTPS (TLS) traffic using the SSL Key Log File | Wireshark @Windows 10

To go through the following practice, services offered by a network traffic capturer will be required. I opted for Wireshark, which can be downloaded from its official site https://www.wireshark.org/#download. It is easy to install and free to use.

TLS traffic decryption with the key log file

1. Introduction

To ease the comprehension of what follows, some important and recurrent terms will be introduced. The reader is also provided with a schematical representation of the TCP/IP model oriented to the content of this post.

1.1. HTTP and HTTPS protocols

Both HTTP and HTTPS belong to the application layer within the established TCP/IP hierarchy (see the image above). The main difference is that HTTPS provides a secured communication where the flow remains encrypted. This way, sensitive data can not be interpreted if captured.

HTTP, on the other hand, shows the transferred content, exposing any type of confidential information (images, documents, passwords, etc.) or not. This also occurs with FTP, SMTP, NNTP, POP, IMAP, TELNET, and RLOGIN.

HTTPS owes its main feature to TLS, a transport layer protocol. It enables the secure exchange of packets.

1.2. TLS protocol

TLS is a secure transport layer protocol and its operation is based on the use of digital certificates. A digital certificate is nothing more than a document that legitimizes the authenticity of a computer or entity thanks to the fact that a CA (Certificate Authority) has signed its public key.

1.2.1. Digital certificates

Pongamos como ejemplo a blogger.com. Esta entidad tiene a su disposición una public key y una private key. Blogger se identifica con la primera ("Hola, yo soy blogger.com") pero, ¿puedo estar seguro de que es realmente quien dice ser? Aquí entran en juego las CA.

Let's take blogger.com as an example. This entity has at its disposal a public key and a private key. Blogger authenticates itself with the former (“Hello, I am blogger.com”) but can I be sure that it is really who it claims to be? This is where CAs come into play.

GTS AC (Google Trust Services Certificate Authority) is responsible for verifying the identity of blogger.com. It issues a certificate that includes its public key signed by the authority (among other information).

Google has signed blogger's public key with its own private key. It can be said that these are used to perform "private and sensitive tasks" (signing, decrypting information...). Therefore, ensuring their confidentiality is essential.

1.2.2. TCP and TLS Handshakes

There is a procedure for traffic encryption and key exchange between computers known as TLS Handshake. This is preceded by a TCP Handshake, which is responsible for establishing communication.

The image above shows the TCP/TLS packet flow analyzed to explain this handshaking. It is part of the example capture that will be used in this post and will be studied later. As can be seen, the TLS Handshake follows the TCP Handshake.

In TCP handshake image above, an initial packet is sent with the SYN flag active. If the destination responds with a SYN-ACK, it means that it is available, to which we will respond again with an ACK (a mere acknowledgment).

Read more about these flags in "An implementation for UDP & SYN Stealth (TCP) port scan | Scapy - Ubuntu 18.04".

After the client-server connection has been established, the TLS handshake makes way for the TLS handshake, which will exchange the specifications necessary to encrypt the data connection and make it more secure.

The information visible in this procedure is limited because, until we decrypt it later, we will not be able to view certain encrypted application data (Encrypted Application Data in Wireshark).

In this process, both machines agree on certain details that will condition how the connection will be encrypted. This does not always result in this exact sequence but, for this example, it will be like this. Some of the data common to all these frames are:

• Content Type -> Handshake/Change Cipher Spec.
• Length -> Packet size in bytes.
• Version -> Highest TLS version supported by the client/server.

Each of them provides some relevant information. Client Hello offers a set of cipher suites, session IDs, a random key, and so on. 

The next two messages that are sent by the server are Server Hello, Change Cipher Spec, Application Data.

• Server Hello -> Shows the selected cipher suite, mainly.

• Change Cipher Spec -> A message that simply shows that the cipher specifications are being exchanged.

• Application Data -> Encrypted application data.

On the other hand, we have Application Data, Application Data, Application Data, Application Data, Application Data (Second message sent by the server -> 151.101.1.16). As is evident, this message is encrypted and we cannot yet view some of the information it contains.

The last message is sent to the server Change Cipher Spec, Application Data.

Read more about this at https://blog.catchpoint.com/2017/05/12/dissecting-tls-using-wireshark/.

1.3. SSL Key Log File

The SSL Key Log file is a text file in which TLS session keys that have been used by your browser when accessing a website are stored. These are necessary to decrypt intercepted traffic. For security reasons, it is only possible to generate this file for one user at a time.

In Windows, it can be done from the environment variables. We create a new variable for our user that obeys the name of SSLKEYLOGFILE and we locate it in the route that we want.

Now you should have a text file in the indicated location that will be updated with the different keys that your browser processes. If it does not appear, try restarting the computer. It looks like this:

2. Capturing network traffic with Wireshark

For this example I have captured the traffic resulting from loading the content of a web page: https://www.xataka.com/categoria/seguridad. The result collects certain encrypted frames that we will decrypt next to see what additional information can be displayed.

2.1. Decrypting captured HTTPS traffic thanks to the SSL Key Log File

We need to tell Wireshark where the sskley we generated a moment ago is located. With it, it will be able to decrypt certain fields of some frames that we could not see before.

To do so, go to Edit>Preferences>Protocols>TLS and click on Explore in the Pre-Master-Secret log filename field. Select the log file and you will have it.

2.2. Analysis and comprehension of the resulting decrypted data

In first place, the TLS stream (encrypted) is shown:

As previously stated, there is a lot of hidden information whose origin we cannot determine. After decrypting the packages, significant differences will be evident.

We can now visualize certain fields from the packages captured during the TLS Handshake. Before, these were shown as Application Data, nothing more nothing less.

• Encrypted Extensions

Note that the field from the bottom left indicates Decrypted TLS. Which verifies we are succesfully seeing decrypted data.successfully

• Certificate y Certificate Verify -> Server exposes its digital certificate so the client can verify it.
• Finished -> Indicates that the client or server is ready.
• New Session Ticket -> Limited time session ticket used in the client random key and the server pre-master secret key exchange.

How this handshake follows may vary depending on the encryption algorithm used. In this particular scenario, TLS_AES_128_GCM_SHA256 is being used.

3. Applications and utilities of a good practice

The main application of this type of practice is the monitoring of traffic flowing in a private network, for example in a company. This way it is possible to control what information leaves and enters the network in encrypted form. Some of its uses in the business environment are as follows:

• Detect potential malware intrusions.
• Prevent from confidential data leaks.
• Define rule-based monitoring policies to determine what kind of data will or will not be decrypted.

4. References

Eulises Ortiz, Ángel. (2019). ¿Qué es el desencriptado SSL / TLS? (HostDime). Retreived from: https://www.hostdime.com.pe/blog/que-es-el-desencriptado-ssl-tls on March 2021.

CloudFlare. (2019). What Happens in a TLS Handshake? | SSL Handshake. (CloudFlare). Retreived from: https://www.cloudflare.com/es-es/learning/ssl/what-happens-in-a-tls-handshake on March 2021.

CloudShark. (2020). All about SSL key logging. (CloudShark). Retreived from: https://cloudshark.io/articles/2015-05-14-all-about-ssl-key-logging on March 2021.

GlobalKnowledge. (2012). What is the Difference Between Ethernet II and IEEE 802.3? (GlobalKnowledge). Retreived from: https://www.globalknowledge.com/us-en/resources/resource-library/articles/what-is-the-difference-between-ethernet-ii-and-ieee-8023/#gref on March 2021.

Vivekananda, Vidhatha. (2017). Dissecting TLS Using Wireshark. (Catchpoint). Retreived from: https://blog.catchpoint.com/2017/05/12/dissecting-tls-using-wireshark on March 2021.

This post is also available in Spanish in "Descifrar tráfico HTTPS (TLS) mediante el SSL Key Log File | Wireshark @Windows 10".