In August of 2018, the Internet Engineering Task Force (IETF) moved Transport Layer Security (TLS) Version 1.3 to RFC 8446. In the world of networking standards, this means it has been properly vetted by the community and is officially ready for showtime on clients and servers.
About these captures
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.
What is TLS?
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.
Reducing handshakes and “round trips”
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.
TLS 1.2 handshake sequence
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.
Here's the frame decode of the Client Hello (protip: Option+Click or Alt+Click on any of the decode-tree elements to expand all the sub-elements too!):
TLS 1.3 handshake sequence
The TLS 1.3 sequences makes this process less chatty by:
- Reducing the number of cipher suites allowed in the protocol. This also has the benefit of increasing security because older suites have been obsoleted.
- Allowing the client to send its key share for the suite it expects to be accepted. If it’s the one the server will use, this eliminates many negotiation steps.
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.
Here's the frame decode of the Client Hello:
Zero Round Trip Time Reduction (0-RTT)
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.
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.
Here's the frame decode of the second Client Hello:
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 has had TLS 1.3 deployed for their services even before its official release, and have had a lot of experience with it.