TLS 1.3 has myriad improvements over its predecessors, including a new handshake and revamped cipher suites.
Before anyone points out that the IETF published TLS 1.3 as RFC 8446 almost a year ago – we know. We covered that. But we realized we hadn’t done an in-depth explainer of the new protocol version yet, and given the number of questions we field about TLS 1.3 on a regular basis – we thought maybe this would be a good time.
Technically, TLS 1.3 is the seventh iteration of the SSL/TLS protocol. SSL 1.0 was never officially released, 2.0 and 3.0 were short-lived (albeit not entirely dead yet). And then TLS 1.0 was introduced as a replacement to SSL. There were some technical differences between SSL and TLS – namely, at first, whether the connection began by port or by protocol – but the premise was largely the same. TLS 1.0 was replaced by 1.1, which was succeeded by TLS 1.2 two years later in 2008. TLS 1.3 was finalized last Summer.
While, intuitively it would seem that the biggest difference between two successive protocol versions would be the switch from SSL 3.0 to TLS 1.0, it’s probably fair to argue that TLS 1.3 is far more different from TLS 1.2 than 1.0 is from SSLv3.
So, today we’re going to take a look at what exactly has changed in TLS 1.3 and what benefits those changes bring to security and performance on the web.
Let’s hash it out.
TLS 1.3: 10 years in the making
TLS 1.3 (RFC 8446) was released a full decade after TLS 1.2 and took 28 drafts to finally define. It was not always smooth sailing, either. There were problems with middleboxes, there were commercial elements looking to undermine the standard in the interest of traffic inspection. Namely, the financial industry. Additionally, the vetting process takes an eternity when there are this many stakeholders involved.
From the first TLS 1.3 version released on April 17, 2014, all the way to the 28th and final version, these drafts were continuously tested and reviewed by vendors such as Google, Cloudflare, Mozilla, and many others. They would experiment with adding TLS 1.3 support, test it, and report issues as they discovered them. That wasn’t always smooth sailing either. For instance, in February 2017, a proxy issue forced Google to back out of TLS 1.3 support entirely for a little while. Obviously, that caused a delay.
That early testing by major tech players has actually come back to cause it’s share of problems now that TLS 1.3 is finalized, too. We’ll get to that in a minute.
TLS 1.2 vs. TLS 1.3 – What’s the difference?
TLS 1.2 has been serving the internet faithfully for a decade now, yet nearly 25% of the Alexa Top 100,000 still doesn’t support it. That’s problematic, because making the jump from TLS 1.2 to to TLS 1.3 is already a fairly large change. Upgrading from even older protocols will require even more configuration.
Now, that’s not to imply upgrading is prohibitively difficult, it’s more to illustrate that one of the biggest challenges that’s going to face TLS 1.3, at least for the next year or so, is the rate of adoption.
As of the end of last year, just over 17% of the Alexa Top 100,000 supported TLS 1.3.
That number has undoubtedly grown since then, but we’re still a long ways from widespread adoption.
Ok, now let’s look at some of the differences. TLS 1.3…
- Eliminates support for outmoded algorithms and ciphers
- Eliminates RSA key exchange, mandates Perfect Forward Secrecy
- Reduces the number of negotiations in the handshake
- Reduces the number of algorithms in a cipher suite to 2
- Eliminates block mode ciphers and mandates AEAD bulk encryption
- Uses HKDF cryptographic extraction and key derivation
- Offers 1-RTT mode and Zero Round Trip Resumption
- Signs the entire handshake, an improvement of TLS 1.2
- Supports additional elliptic curves
TLS 1.3 Eliminated Vulnerable Algorithms and Ciphers
Time is the enemy of any cryptosystem. Always has been, always will be. Over time, vulnerabilities and exploits are found that make continued use of a given algorithm or cryptosystem a potential risk.
Now, let’s address something that I feel gets left out of a lot of discussions about vulnerabilities and potential attacks: many of these are prohibitively difficult for all but the most sophisticated actors to pull off. When an issue really is pressing, like Heartbleed – which was actually pulled off successfully in the wild – it gets the attention it deserves. But a lot of others, like POODLE, are demonstrated by researchers in proof-of-concepts and really aren’t the immediate threats they’re made out to be.
That’s not to say they shouldn’t dealt with swiftly, just that the alarm doesn’t need to be raised so high.
Anyways, TLS 1.3 has eliminated support for algorithms and ciphers that are both theoretically and practically vulnerable. This includes:
- RC4 Stream Cipher
- RSA Key Exchange
- SHA-1 Hash Function
- CBC (Block) Mode Ciphers
- MD5 Algorithm
- Various non-ephemeral Diffie-Hellman groups
- EXPORT-strength ciphers
- DES
- 3DES
Simplified Key Exchange
Historically, there have been two popular mechanisms for exchanging the secure session key that will be used during the HTTPS connection following the handshake:
- RSA
- Diffie-Hellman
Diffie-Hellman is a method for both client and server to mutually arrive at the value that is the session key.
RSA key exchange has problems, namely Oracle padding attacks. It’s enough of an issue that last year we started advising organizations to stop using it in their implementations.
The other knock against RSA is that it doesn’t offer an ephemeral key mode. That’s necessary for Perfect Forward Secrecy. Without forward secrecy, if someone saves the encrypted conversation and manages to compromise the private key, they can decrypt that session. This was especially relevant when Heartbleed was wreaking havoc as it allowed for the theft of private keys. Forward secrecy protects against that, which is why it’s now mandated in TLS 1.3.
So, RSA is out, along with all static (non Forward Secret) key exchanges while ephemeral Diffie-Hellman families are in.
Here’s the other benefit, because RSA has been eliminated as a key exchange option, the client initiating the TLS handshake knows it’s going to be a Diffie-Hellman family and can “guess” by sending the requisite randoms and inputs needed for key generation during its “hello.”
That effectively eliminates an entire round-trip on the handshake, reducing the time it takes and improving the overall performance of the website.
That leads perfectly into…
TLS 1.3 is faster because its handshake has been refined
As we just alluded to, at the outset of any HTTPS connection, the client and server perform an SSL/TLS handshake. In TLS 1.2, it takes two round-trips from both sides to complete a handshake.
In TLS 1.3, that’s been reduced to just one round-trip. That’s because the number of negotiations taking places has now been cut down from four to two. Key exchanges, and by extension the digital signature scheme no longer require negotiation.
Now, quickly, this is one round-trip under optimal circumstances, realistically it can sometimes take more because things don’t always operate under the optimal circumstance. Either way, a shorter TLS handshake means connections to the site get made faster – with less latency.
Now, the difference is in milliseconds, which seems beyond negligible to a single person. But at scale it adds up. Enterprises are always looking for ways to improve network performance, which TLS 1.3 accomplishes.
Another feature that will make TLS 1.3 faster is ‘Zero Round Trip Time Resumption’ (0-RTT). This feature allows for near-instantaneous session resumption for visitors who have recently visited your site. On mobile networks and at scale, this speed change is pretty noticeable.
In TLS 1.2, there are a couple ways to resume a connection: session IDs and session tickets. That’s been combined into a pre-shared key in TLS 1.3. Much like the client and server generate session keys to use during the connection, once the connection has been established they can use a similar function to generate a “resumption master key” that facilitates 0-RTT.
When the client and server want to resume a session, the resumption master key is used to encrypt some application data for the server, which is sent along with the session ticket. The server validates it and the session resumes.
AEAD Bulk Encryption
Bulk encryption is another way to refer to symmetric encryption. Traditionally there have been two ways to handle this:
- Blocks
- Streams
Stream ciphers, as the name so aptly applies, create streams of pseudo-random data of arbitrary length.
A new wrinkle has been added in TLS 1.3 though: encryption and authentication have been combined into a single element. Message Authentication has always been a part of SSL/TLS – otherwise it would be too easy to slip encrypted, malicious packets into the connection.
But, historically these two things have been decoupled. This new type of symmetric construction is called Authenticated Encryption with Additional Data (AEAD).
AEAD is a variant of Authenticated Encryption. There are generally a few accepted approaches to AE.
Encrypt-then-MAC (EtM)
MAC stands for Message Authentication Code. In this approach, the plaintext is encrypted first, then a MAC is produced via a hash function that’s based on that ciphertext, then the two are sent together. This is the strongest method provided the MAC is “strongly unforgeable,” which means it has the appropriate level of entropy.
Encrypt-and-MAC (E&M)
Encrypt-AND-MAC derives a MAC from the plaintext (still a hash function), the plaintext is then encrypted WITHOUT the MAC and both the MAC and the ciphertext are sent along.
MAC-then-Encrypt (MtE)
The plaintext is used to generate the MAC, then BOTH the MAC and Plaintext are encrypted together and delivered.
MAC-and-Cheese (Mmm)
Simplified Cipher Suites
Now that half of the negotiations have been eliminated from the handshake, the size of the cipher suites has shrunk, too.
TLS 1.2 and its predecessors use Cipher Suites that include 4 ciphers. Here’s an example:
In TLS 1.3, cipher suites no longer include the key exchange and signature algorithms. Now it’s just the bulk cipher and the hashing algorithm.
One of the biggest problems with TLS 1.2 was the acronym soup that drove the number of possible cipher combinations up into the dozens. That was nightmarish because there was too much choice – with little guidance on which cipher suites to support.
That has been whittled down substantially for TLS 1.3, to the point where there are now just five recommended cipher suites:
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256
Who Supports TLS 1.3
When we answer this question, it really depends on whether you mean client-side or server-side. Most popular browsers already support it from the client side.
- Google Chrome – Version 67+
- Mozilla Firefox – Version 61+
- Apple – Mac OS 10.3 & iOS 11
Microsoft has been a bit slower updating its operating system and browsers. Chromium-based Edge browsers support it, but the rollout has been slower in other areas.
Here’s a chart that shows client-side support:
How do I upgrade to TLS 1.3 on my server?
Upgrading to TLS 1.3 is really as straightforward as updating the software library you’re using. You simply need to update your SSL/TLS library to one of these versions:
- OpenSSL 1.1.1
- GnuTLS 3.5.x
- Google’s Boring SSL (current)
- Facebook’s Fizz (current)
There may some configuration required, which will vary by server, but the bulk of the heavy lifting will come when you upgrade your software library to a version that support TLS 1.3.
Troubleshooting some common TLS 1.3 errors
There are a couple of problems you may run into when implementing TLS 1.3. Neither of them are particularly worrisome, but it’s worth pointing them out anyway.
Browser Errors
Google Chrome users attempting to reach your website might get an error that says:
ERR_SSL_VERSION_INTERFERENCEThis indicates that there is no mutually agreeable TLS version available for the client and server to use for their connection. This can happen for a number of reasons, the most prevalent being that the server only supports TLS 1.3 and the client doesn’t.
This is why, at least for a few more years, leaving legacy support for TLS 1.2 is important. That’s already the reason some servers still support TLS 1.1 and TLS 1.0: older clients can’t connect to with the new protocols.
But we’ve reached the point where interoperability is beginning to hurt security too much, which is why both of those protocol versions will be completely deprecated come January 2020.
Running old versions of TLS 1.3
One of the other problems you may run into was born out of the draft process and then numerous versions that were penned before the protocol was finalized.
As we discussed, the way these drafts were vetted was live testing. Various browsers and platforms implemented early versions of 1.3 to see how it fared. That means there are a bunch of different versions of TLS 1.3 out there – and not all of them play nicely together.
Make sure you and your customers are using the latest versions of your respective browsers, OSs and software libraries. Trying to connect with an outmoded draft version of TLS 1.3 can cause errors and problems.
Start using TLS 1.3
TLS 1.3 has been official for almost a year now, yet it hasn’t been as widely adopted as some hoped. Given the rate of adoption for TLS 1.2, which took ten years and still hasn’t reached its intended goal, it may be foolish to hope that the internet will make the move quickly.
But, with HTTPS and SSL/TLS now mandatory and the internet at large more acutely aware of cybersecurity and the need for it – maybe we’ll see it become the norm in the next 2-3 years.
That all starts with you. The benefits are clear. It’s more secure. It’s lighter and faster. And it shows your organization is forward-thinking when it comes to securing itself and its customers.
