Akamai Diversity

The Akamai Blog

TLS 1.3 FTW

In common slang, FTW is an acronym "for the win" and while that's appropriate here, I think a better expansion is "for the world."

We're pleased to announce that we have sponsored the development of TLS 1.3 in OpenSSL. As it is one of the most widely-used TLS libraries, it is a good investment for the overall health and security of the Internet, so that everyone is able to deploy TLS 1.3 as soon as possible.

There are a couple of reasons why TLS 1.3 is important. First, TLS 1.3 always uses Forward Secrecy (PFS). Consequently, if traffic is intercepted, or if long-term TLS certificate private keys are exposed, there is no common key so each session is separately protected. Second, it only uses strong ciphers (AES-GCM and ChaCha-Poly) so it will be easy to configure applications that are secure by default. Finally, it has a way for clients to reconnect to a server to which they have previously connected, so that an entire network round-trip can be avoided.

A related feature, known as "early data," allows clients to send data with their first connection message, albeit with slightly less security (no protection against replay). For most HTTP (or even more so,  HTTP/2) traffic, this is probably an acceptable tradeoff of security versus performance. When coupled with other speed-ups like TCP FastOpen, it can mean that users can connect to their favorite website, and start seeing the page display with a single packet exchange, rather than the current three or more.

TLS 1.3 has been in development at the IETF for some time. As the working group is winding down, there's been work among many major implementers to implement the protocol, find bugs, and test for interoperability.  Recent IETF Hackathons have included Mozilla's NSS (used in Firefox), Facebook server (fizz), Google's BoringSSL (which powers their servers and Chrome), a Go implementation from CloudFlare, and other commercial offerings.

Notably absent from that list was OpenSSL. One reason why is that the OpenSSL team was just finishing the 1.1.0 release, which was a major effort. One reason is that the team doesn't have the resources to track all the changes made to drafts, and was concerned that if there were an official release before the standard was finished, it would be difficult to get all downstream consumers to upgrade. Because of its huge installed base, release adoption can be slower than, say, a single auto-update. Plus, backward compatibility is very important. Combined,  this makes OpenSSL fundamentally different from those other participants.

At a face-to-face team meeting in October 2016, the OpenSSL development team decided that TLS 1.3 would be the focus of the next release and that it would be 1.1.1 to maintain API/ABI compatibility with the then-current 1.1.0 release. The effort in 1.1.0 to make data structures opaque is an important factor in being able to ensure this compatibility.

So today we have a specification that is almost ratified and an important TLS toolkit ready to implement a specification that is just about finished. The stars were in alignment, it's an incoming perfect storm, or whatever cliche you like.

The only thing missing was being able to commit to a delivery date, so that downstream consumers (such as Akamai) could dependably plan their own TLS 1.3 rollouts.  Because of our sponsorship, OpenSSL will deliver TLS 1.3 on April 5, in a version compatible with 1.1.0.  Akamai will begin incorporating this update into its systems soon thereafter.

If you have applications that use OpenSSL, start migrating to OpenSSL 1.1.0 now. Then, when the version supporting TLS 1.3 is available, you can just "drop it in."  If you don't have applications to migrate, then follow along on the GitHub repository; same basic interop is already working.  Let the countdown to global TLS 1.3 enablement begin!

3 Comments

Hi Rich,

I'm the maintainer of ucspi-ssl and currently struggling with OpenSSL 1.1.0 compatibility.

Actually I question your sentence 'make data structures opaque is an important feature to compatibility'. We are taking about the ASN1 structures, n'est-ce-pas?

I can't see a correlation with the change in the TLS handshake protocol. What do the other TLS providers, like the guys from LibreSSL think about that?

Best regards.
--eh.

Sorry I wasn’t clear. This is not about changing the wire protocol, but rather making the C structures that OpenSSL uses opaque. For example, the fields in an SSL object are no longer directly available; you have to use the defined accessors and settors. This lets us change the contents, and size, of that SSL structure without breaking API or ABI compatibility.

Just wanted to clarify that I wasn't saying there would be a *release* on April 5 -- OpenSSL sets its release schedule -- but that the code would be available. And it is, in master; and it interoperates (separate branch for Draft-18).

Sorry for the confusion caused by using "deliver" rather than something like "make available."

Leave a comment