Decrypting SSL/TLS #3: Understanding the Differences Between TLS 1.2 and TLS 1.3 from Packet Data

English Contents

 

*This article is an English translation of the Engineer Notes article as of Nov 8, 2022.
*Please note that the content may have been updated since then.

Original Article

Decrypting TLS #2 examined the communications between SYNESIS and a Windows PC using decrypted packets. I observed significant differences in behavior between TLS1.2 and TLS1.3. This post explains the comparison results and the differences between TLS versions.

As in the previous post, this examination was conducted using Wireshark Ver.3.6.8.

Browser Settings for Communicating with TLS1.2

The experimental environment is the same as in Decrypting TLS #2. However, to communicate with TLS1.2, either the server or client settings need to be changed. In this case, we modified the client-side (browser settings).

To change the TLS version in Firefox, follow these steps:

  1. Type "about:config" in the Firefox address bar and press Enter.
  2. Click "Accept the Risk and Continue" on the warning screen.
  3. Set the values of "security.tls.version.min" and "security.tls.version.max" to "3". Use the search box to find these parameters quickly. Double-click to edit the values.

The version indicated by the values is as follows:

Value Version
0 SSL3.0
1 TLS1.0
2 TLS1.1
3 TLS1.2
4 TLS1.3

In recent versions of Firefox, security.tls.version.min is set to 3 (TLS1.2), and security.tls.version.max is set to 4 (TLS1.3). These settings are generally recommended for security. While we temporarily changed these settings for the experiment, permanent changes should be discussed with your system administrator to avoid lowering the security level. (I reverted to the original settings after the experiment.)

TLS1.2 vs TLS1.3

The results for TLS1.2 are as follows:

Pre-decryption TLS Communication Status - TLS1.2

Pre-decryption TLS1.2

Post-decryption TLS Communication Status - TLS1.2

Post-decryption TLS1.2

Even at a glance, compared to Decrypting TLS #2, there are many more steps before HTTP2 communication begins. To make it easier to understand, I have summarized it in table format.

TLS1.3 Negotiation

# Direction Info Encrypt
4 Client → Server Client Hello -
6 Client ← Server Server Hello, Change Cipher Spec, (Encrypted Extensions) Y
7 Client ← Server (Certificate), (Certificate Verify), (Finished) Y
9 Client → Server Change Cipher Spec, (Finished) Y

In the case of TLS1.3, the number of negotiations is reduced, and data encryption starts midway. The data in parentheses is encrypted.

TLS1.2 Negotiation

# Direction Info Encrypt
4 Client → Server Client Hello -
6 Client ← Server Server Hello, Certificate -
7 Client ← Server Server Key Exchange, Server Hello Done -
9 Client → Server Client Key Exchange, Change Cipher Spec, Finished -
11 Client ← Server New Session Ticket, Change Cipher Spec, Finished -

For TLS1.2, negotiation packets are not encrypted.

Journey to IETF Standardization

Now that we've looked at the packets, let's review the journey to IETF standardization. You can track the history from the RFC discussion stages on the IETF Datatracker. This site is a database of IETF documents, working group minutes, presentations, and more.

You can find the history up to the issuance of RFC8446 in The Transport Layer Security (TLS) Protocol Version 1.3 RFC8446. Specification development began in 2014, with draft versions up to draft28 being released, and the official RFC was issued in August 2018. It took four years to finalize the specification.

Differences Between TLS1.3 and Earlier Versions

The blog post from IETF-TLS1.3 highlights how thoughtfully TLS1.3 was developed. It describes improvements, which I have summarized below. I encourage you to read the original content for a sense of the enthusiasm during its release.

Main Improvements in TLS1.3

Security - Vulnerabilities found in TLS 1.2 have been addressed in TLS 1.3, supporting only algorithms without known vulnerabilities.

Performance - TLS 1.3 reduces the overall round trip in handshakes. In typical cases, a new connection completes in a single round trip between the client and server.

Privacy - By encrypting the negotiation handshake, it protects data exchanges from eavesdroppers. It also enables forward secrecy by default.

>Seeing raw packets during the review of the specifications is indeed the first step towards understanding the protocol.

Naming of TLS1.3

Given the significant differences and lack of compatibility between TLS1.3 and previous versions, there were opinions during the specification stage that the version number "1.3" should be changed. At IETF97, a humming vote was conducted with options like "TLS1.3", "TLS2.0", "TLS2", and "TLS4". The "TLS1.3" option received the most support, and after further discussions, it was officially released as "TLS1.3".

Afterword

Writing about TLS ended up being more extensive than I expected, resulting in a three-part series. During this time, Wireshark Ver4.0 was released, but I held off on upgrading for consistency. Now that the testing is complete, I look forward to trying Ver4.0.

The name TLS1.3 was decided by a humming vote at IETF97. Speaking of which, IETF115 is currently being held in London. What decisions will be made this time? And IETF116 will be held in Yokohama. I'm looking forward to it.