A new version of TLS doesn't mean much to most people, but version 1.3 changes the game for many of us.
Arguably the two biggest impacts 1.3 will have on most of us is the much more rapid handshakes, down from two round trips to one, and potentially none on recurring connections, and the much simplified cipher options available to users—following a continuing trend of supporting fewer, better cipher suites.
While it may still be a year or two before 1.3 dominates the web, it's good to get excited about it now, as it really sets the stage for HTTPS everywhere, and brings performance and security together.
If you happen to be one of the many who still refer to secure internet connections as SSL, it's really definitely time to learn to say "TLS"; not only does it roll off the tongue nicer, it's also the thing you've actually using since the dawn of the millennium. None of the cool kids make that mistake anymore, and you should feel unjustifiable social pressure to switch.
TLS 1.0 came about built on the shoulders of SSL 3, and TLS 1.1 was basically a minor patch to fix the way certain cipher suites were behaving badly in TLS 1.0. TLS 1.2 was similarly released to further shore up some insecure hashing algorithms, and to introduce some of the newer and safer algorithms we enjoy today.
TLS 1.3 is not a minor patch.
In TLS 1.3 we move to a complete restructuring of the handshake, and drop all of the problematic ciphers that have continued to cause entire families of attacks against TLS communications.
This is no small diff, so read on to make sure you understand what goodies await you.
Let us let you in on a little secret: web performance is all about the latency. Shuffling packets back and forth quickly eats up your users' precious attention span. There are countless tricks to breaking up your site so that it's usable with as few round trips as possible, and soon using TLS 1.3 will be one of them.
TLS 1.3 has half as many round trips as TLS 1.2, meaning that it's already twice as fast, out of the box.
What's more, TLS 1.3 supports a safer zero round trip mode (0-RTT) which effectively wipes out any cost from using TLS. That's a game-changer, and the final blow to many who were still waiting to go HTTPS Everywhere because "HTTPS is slow".
Let's quickly draw out how TLS handshakes have been working up until now.
Okay, so here we see the standard TCP handshake, followed by a TLS handshake involving the client sending a ClientHello message with all of its session and cipher preferences, the server responding with its selected cipher and its Public Certificate in the ServerHello message, the client verifying the certificate, and sending back its encrypted key, followed finally by the server acknowledging with a ServerFinished message.
Under the single roundtrip mode (1-RTT), the client initiates the handshake with a ClientHello which includes the parameters to be used in the final chosen cipher suite. The server then need only reply with the authentication and encryption keys to complete the handshake.
In the event that the server doesn't support the ciphers sent along with the ClientHello method, it can always fall back to a more TLS-1.2-like mode by replying with a HelloRetryRequest, initiating another more compatible ClientHello.
What's really exciting is what can happen when a client and server are communicating on subsequent sessions; TLS 1.3 also has a zero round trip capability (0-RTT) which lets the client bundle its TLS negotiation parameters and its initial HTTP request together, meaning that no additional trips have to be made to the server to establish a new secure session.
What magic lets you encrypt an HTTP request with an incomplete TLS negotiation, you undoubtedly ask? Essentially, once a client and server have already had a TLS conversation, the client is free to reuse the encryption key from the previous session for that initial HTTP request, though all subsequent traffic must be encrypted with the key that is being negotiated in parallel.
One of the big departures from TLS 1.2 is that TLS 1.3 no longer supports cipher suites that don't offer Perfect Forward Secrecy. Practically, that means that RSA is out, as is simple DH, which pretty much leaves DH's much cooler variants, DHE and ECDHE (see our intro to cipher suites for an exploration of each). It's not that RSA couldn't support ephemeral keys, it's just that it's not very good at it, and no one every really bothered to implement it.
On the upside, that means that handshakes are usually going to require only Diffie-Hellman parameters to get underway, which is of course why an optimistic 1-RTT handshake is now practical.
TLS 1.3 comes with far fewer cipher suites and options to configure. No really. You can count them on the digits of a non-mutated human. If that doesn't excite you, you've probably never had to configure a web server before. In fact, you likely don't need large and expansive primers on web ciphers anymore. What this means is that you have far less to worry about to get a secure configuration up and running.
Fewer, better options has been a growing trend in web security for some time, with the idea that by focusing on a few known entities there's much less risk of some obscure configuration combination proving to be vulnerable. This has led to an interesting counterpoint, discussed below.
To begin with, TLS 1.3 only supports AEAD suites with DHE and ECDHE. Much of our earlier cipher suite woes came from the permutations of cipher suite options, and with fewer options, we can get this down to a human level.
In fact, if you head over to the current TLS 1.3 draft on Github you can see them neatly listed.
Take a look.
Assuming you did, you have now returned with the astonished realization that only 5 cipher suites appear where historically there have been... well, many more.
Since (EC)DHE is assumed, those no longer have to be part of the suite signature, which simplifies things greatly. (In case you're wondering, you indicate EC/DHE support in the Negotiated Groups parameters).
So... about those (EC)DHE parameters. There was this time the NSA tried to sneak a weak EC curve into the standards... Ya. True story.
As a result a lot of people became mistrustful of elliptic-curve cryptography, which is a shame because it's a pretty great boost to security and performance.
Keeping with the "fewer and better" approach, TLS 1.3 only supports a limited set of DH parameters and EC curves. (Incidentally this is party of why 1-RTT is so easy for TLS 1.3)
From many points of view, so few options sound incredibly dangerous. What if some brilliant mathematical attack is released tomorrow against the way GCM is implemented?
Would we all be doomed if there's nothing else to fall back on?
(For the record, that's just fear mongering... we have little worry that GCM is broken, and there's always CCM.)
There's also the growing popularity of the Bernstein-algorithms, documented well by Peter Gutmann. (Of course, Bernstein happens to authour excellent crypto, so maybe it's just that.)
It's certainly a risk, but not one that shakes the faith in any of the cryptographers working in the TLS 1.3 work group. Of course, when it happens, we'll eat our hats.
You're probably itching to try out TLS 1.3 at this point, and we don't blame you.
Chrome Canary, Firefox Nightly, and Opera's developer build all support TLS 1.3, so you can get cracking right away, provided you have a server kicking around that supports it. (We've seen a C and Go implementation, but expect a flurry of new ones once the standard is finalized.)
Yep, we also support a check for TLS 1.3 support and configuration in our Basic Tier, just in case you wanted to be notified when your providers started implementing.
There are a bunch of other fun, subtler points to TLS 1.3 that you probably don't care about nearly as much as the performance boost and simplicity above. We've rounded up a few of our favourites here anyway, since if you've read this far you may as well keep going.
TLS 1.2 supported TLS resumption, but they kind of goofed its implementation, (no judgment, crypto is hard). TLS 1.3 formalizes much stricter resumption standards, and thanks to these efforts, the 0-RTT pattern is possible.
Plenty of attacks used the ability to sabotage the cipher suite negotiation to force the use of insecure suites. No more! TLS 1.3 signs those bad boys.
Both of these were the source of some subtle and less-subtle attacks, so they're gone.
Ever wonder what a protocol would be like if it were passive-aggressive?
Look no further!
GREASE is a great way to deter server developers from stalling future TLS releases by failing to handle unexpected versions in the handshake gracefully. They do this by sending random version numbers mixed in with the legitimate ones to keep servers on their toes.
Hopefully you're sufficiently excited by this point and are eagerly awaiting TLS 1.3. You can expect standard acceptance in the later half of 2017, but you can certainly start preparing now.
Welcome to a safer and faster world!
Subscribe to get new resources like this one, and to be notified of updates.
Subscribed! An email confirmation has been sent.