I explained in Decrypting SSL/TLS #1 how to configure Wireshark to decrypt SSL/TLS traffic. This time, I will use that configuration to examine the decrypted packets.

As a side note, Wireshark Ver.4.0 has finally been released. However, since the previous article was written using Ver.3.6.8, we will continue to use the same version for this explanation.

Structure of TLS Packets

Before examining the packets, let's overview the structure of TLS packets. TLS consists of two protocols: the "TLS Handshake Protocol" and the "TLS Record Protocol".

The TLS specification is released in RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3. Although the title indicates TLS1.3, it also specifies requirements for implementing TLS1.2. Please note that RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 has been deprecated. For details on each protocol, refer to RFC8446, specifically the sections on 4. Handshake Protocol and 5. Record Protocol.

Experimental Environment Used

In this experiment, we will observe the communication between SYNESIS and a Windows PC. SYNESIS is a packet capture device developed and sold by our company. It features a user-friendly web-based GUI and is well-received both domestically and internationally. For this experiment, we will use SYNESIS as a web server.

The configuration is as follows:

The Client PC connects to SYNESIS using the recommended browser, Firefox. Following the method of registering the Pre-Master Secret for each session as explained in Decrypting SSL/TLS #1, we set the SSLKEYLOGFILE environment variable on the Client PC before communicating with SYNESIS. This communication is captured and decrypted using Wireshark on the Client PC.

Decrypting Communication Packets with SYNESIS

Let's take a look at the captured results. First, let's see the packets without registering the Pre-Master Secret. For clarity, we are displaying "Server" and "Client" instead of IP addresses.

Starting from frame number (denoted as #) 9, the display differs. When not decrypted, the encrypted data portion is shown as [Application Data].

This raises a question: although the List pane shows "TLS 1.3", the Detail pane displays the version as "TLS 1.2 (0x0303)".

Traditionally, this field was supposed to be SSL3.0=0x0300, TLS1.0=0x0301, TLS1.1=0x0302, and TLS1.2=0x0303. Upon investigation, it was found that the reason is described in RFC8446 - Appendix D. Backward Compatibility. In TLS1.3, this field is not used, but for backward compatibility with servers that do not support TLS1.3, the field stores "0x0303" when TLS1.3 is supported. Therefore, the discrepancy between the Version field and the actual version is normal.

The actual negotiation of the TLS1.3 version is done using the Supported_versions parameter between Client Hello (#4) and Server Hello (#6).

The client presents the versions it supports to the server, and the server sends the most optimal version it supports back to the client, completing the negotiation.

Afterword

In this article, I examined actual packets based on the Wireshark settings from Decrypting SSL/TLS #1. Seeing actual packets deepens our understanding of RFCs. SYNESIS, for security reasons, supports only TLS1.2 and TLS1.3, which are generally the most recommended protocols. During the investigation, we found significant differences between TLS1.2 and TLS1.3 specifications. Next, I will use the same SYNESIS to compare communications between TLS1.2 and TLS1.3.

For this article, I referenced the following sites as much as the RFC. Their well-organized content was extremely helpful:
The Illustrated TLS 1.3 Connection
The Illustrated TLS 1.2 Connection