5 min read
Transport Layer Security (TLS) version 1.3 has some rather important improvements over TLS 1.2. Released in 2018, it will still take awhile for most application to migrate towards using it. Here's a quick overview of the benefits, with real packet capture examples.
If you’re not familiar with TLS, it’s the protocol that allows applications to communicate data securely between two points. Security is generally comprised of several component concepts, including authentication, authorization, and encryption. TLS uses the Public Key Infrastructure (PKI) to provide authentication and includes a process both client and server can use to agree on an encryption mechanism.
TLS itself was originally defined in IETF RFC 2246 (version 1.0). Version 1.2 was defined in RFC 5246 as an evolution to Secure Socket Layer (SSL) and has been in use for a long time. As the number of networked applications has increased, the drive to make TLS more efficient gained momentum, and TLS 1.3 was released.
TLS 1.3 is defined in IETF RFC 8446, and has a great overview of the changes from TLS 1.2.
We're able to look at TLS 1.3 handshakes thanks to support for the protocol in tshark 2.6. CloudShark 3.5 and later versions have support for TLS 1.3 decodes as a result.
We took these captures using OpenSSL version 1.1.1-pre8 and the built in s_server and s_client applications.
When analyzing TLS captures, you'll notice that the frame decode window still contains the protocol fields under "secure socket layer", or SSL, so don't be confused when expanding these frames in the examples.
TLS involves a negotiation process between the client and the server to choose the appropriate cipher suites to be used and other settings. This negotiation is called a “handshake”. In TLS 1.2, this process took several back-and-forth packets between the client and server - each back-and-forth is generally referred to as a “round-trip”. The negotiation needed to complete before the secure session could be established and encrypted application data transmitted. This isn’t a small amount of overhead when you’re doing several orders of magnitude of connections.
Take a look at this TLS 1.2 capture.
The handshake sequence involves a multi-step process in which the client first sends a Client Hello with the cipher suites and extensions it supports. The Server sends back which suite it wants to use, along with its certificate and keys. Even though further handshakes from this point are encrypted, some more communications occur before the secure session is even established.
The TLS 1.3 sequences makes this process less chatty by:
Take a look at this TLS 1.3 capture.
You’ll notice two things right away. For starters, the list of cipher suites in the Cipher Suites field is only four: compare this to the TLS 1.2 Client Hello above where there are 28! You can also see that the Client Hello includes an extension called “key share”, which contains the details for the cipher suite it expects to use. The Server Hello includes its own information, but also immediately begins sending application data, since the negotiation is already complete.
One option included in TLS 1.3 to make connections even faster is called Zero Round Trip Time Reduction, or 0-RTT (a good thing that they abbreviated it). As you might expect, this option allows a TLS session to resume immediately, letting the Client send encrypted application data as part of the Client Hello. This has some security caveats, however, if the stored information is not updated regularly, leaving the system open to replay attacks.
Take a look at this TLS 1.3 capture.
Just like with the capture above, we see a Client Hello and immediate exchange of application data. In our example, we open a second TLS session with the same server, and the pre-shared key is reused. The Client sends encrypted application data right away as part of the new Client Hello.
Note: In our ladder diagram here you can see that we’ve mapped the endpoints to two separate conversations on different ports with the server in the middle. The second connection comes from port 35122.
As TLS 1.3 becomes more widely deployed, you may see it come up when you are troubleshooting your users’ web experience or application performance. Knowing how it works and why can help you determine the root cause of slow web apps or security issues.
These were some examples of TLS 1.3 and TLS 1.2 packet captures so that you can see the differences in some real live data. If you want to go more in-depth, you can see this article and video by the folks at CloudFlare for more information on how it all works. CloudFlare had TLS 1.3 deployed for their services even before its official release, and have a lot of experience with it.
