What is TLS 1.3?

Should I upgrade TLS and what changes are in this version?

Brian Waters
Independent Security Evaluators

--

If you follow the news in computer security, networking, and software development, you may have heard that the IETF TLS working group has recently approved TLS 1.3 to become a new standard. As deployments roll out, developers and administrators will start encountering TLS 1.3 in their daily work — and some will want to deploy TLS 1.3 themselves. So then, what exactly is TLS 1.3, and what does it mean for you?

IETF, WG’s, SSL, TLS, oh my!

The organization that’s actually working on standardizing TLS 1.3 is the IETF’s TLS Working Group. The IETF, or Internet Engineering Task Force, is an open, volunteer- based, non-profit consortium of network engineers who develop Internet standards. It’s split into working groups which work on specific technologies, and the TLS Working Group is the one that works on TLS, or Transport Layer Security. On March 21, the IETF formally approved the latest draft of TLS 1.3 as a Proposed Standard. There is still some work to be done before TLS 1.3 becomes an Internet Standard, but the technical details are now more or less set in stone.

TLS was developed and first released by Netscape as SSL 2.0 in 1995, with the goal of providing a transport encryption protocol for web browsing. SSL 2.0 had a number of security issues, and was replaced by SSL 3.0 in 1996. The next version of the protocol was released in 1999, and was called TLS 1.0. TLS 1.1 and 1.2 followed in 2006 and 2008, respectively. (The key is that SSL and TLS are, confusingly, names for different versions of the same protocol, and are often used interchangeably in practice.) Each version of the protocol fixed known security issues and modernized the protocol’s cryptography somewhat. TLS 1.3 is the latest evolution in this series, and represents the most drastic and forward-thinking change to the protocol thus far.

Major changes in TLS 1.3

From a security perspective, TLS 1.3’s cipher suites have been improved greatly, and some unused or unnecessary features have been removed. (We’ll get to that below.) But it also offers some compelling new features that reduce its handshake overhead considerably, which means shorter page load times for users. On the other had, the improved cipher suites in TLS 1.3 might create issues for enterprise network operators who expect to use intercepting middleboxes to decrypt TLS traffic.

New handshake and 0-RTT session resumption

TLS 1.2 and earlier employed a handshake which required two full round trips to establish a shared cryptographic secret before encrypted and authenticated application data could be exchanged. TLS 1.3 improves this for application protocols like HTTP by piggybacking the client’s first HTTP request onto the TLS Finished message. This is called “1-RTT” (“RTT” means “round trip time”), since it requires one full round trip before data exchange.

Earlier versions of TLS included two mechanisms that allowed clients to resume a previously-established connection with a special handshake that required only one round trip. The first mechanism, based on a special session identifier, required clients and servers to save their session state to a special cache based on a shared session ID. Upon reconnecting, the client would provide the session ID for the previously-established connection in its ClientHello message, and the server would look up the associated session state in a database and respond with a ServerHello and a Finished message. After that, the client sends its Finished message, and immediately begins sending application data. That’s one full round trip.

The second resumption mechanism in older versions of TLS is based on an authenticated and encrypted token, known as a session ticket, stored on the client side, and does not require the server to maintain a database of known session states. Instead, the client sends a session ticket (which was previously provided by the server) in a special extension to its ClientHello message. Upon receipt, the server verifies the MAC on the ticket against a special session ticket key that is stored on the server. If the MAC verification passes, then the server decrypts the token, retrieves the session state from the resulting plaintext, and responds with a ServerHello and a Finished message. After that, the client sends its Finished message, and application data exchange begins. Again, this is one round trip.

TLS 1.3 deprecates both of the legacy session resumption mechanisms, but introduces a new mechanism called PSK (pre-shared key) that is technically distinct from, but conceptually similar to, the older session ticket mechanism (which is explained above). In addition, TLS 1.3 allows the client to piggyback its initial HTTP request onto the ClientHello message (just like in the 1-RTT handshake). In other words, encrypted and authenticated data exchange can begin on the first round trip. The feature is called “0-RTT” because it requires zero round trips between the client and server before application data can be exchanged.

There are two security issues with 0-RTT. The first is that 0-RTT sessions are not forward secret with respect to the session ticket key. (This is not the same as lacking forward secrecy with respect to the server’s private key.) What this means is that, if the server’s session ticket key is somehow compromised, all 0-RTT sessions which used that key could be decrypted, even offline at a much later date.

0-RTT and non-idempotent requests

Second, and much more important, is the fact that 0-RTT session resumption is vulnerable to replay attacks. (In general, it’s hard for cryptographic protocols to avoid this problem without requiring a full round trip.) As such, it’s important that web applications disallow 0-RTT for non-idempotent actions which change something on the server. It’s yet to be seen how servers and web frameworks will handle this. One obvious solution would be for servers to force a full handshake when 0-RTT is used to request a non-idempotent action. HTTP defines which request methods are “idempotent” or “safe,” but in our experience carrying out security assessments at ISE, many web applications use supposedly idempotent methods like GET for non-idempotent actions.

As such, web frameworks may have to implement route decorators which specify which actions are non-idempotent. Many web frameworks already offer such decorators to defend against attacks like cross-site request forgery (CSRF), but again, in our experience, these decorators are often used improperly or ommitted altogether. Unfortunately, TLS 1.3 deployment is still in its very early stages, it’s too early to say for sure how web frameworks and server software will actually handle 0-RTT. Therefore, the best general-purpose advice for web developers may be to disable 0-RTT altogether until a security audit can determine whether GET requests are used for non-idempotent server actions.

CloudFlare has implemented a policy where 0-RTT is only permitted for GET requests without any parameters, but we still see potential for abuse there, particularly in web applications that send their parameters as part of the path URL fragment (e.g, /api/1.0/renewSubscription/689204).

The draft standard for TLS 1.3 lists three methods which servers can use to mitigate 0-RTT’s replay attack problem: the first two methods involve keeping a server-side database which would effectively disallow the same ticket from being used twice; the third uses a timestamp in the ClientHello message to disallow replays outside of a certain time window. These methods are optional, though, and it remains to be seen how widely servers will implement them. Furthermore, each method is somewhat limited in certain circumstances. The third, timestamp-based method can’t stop very fast replay attacks which take place within the pre-configured timeout period. And the first two methods, which rely on a server-side cache of once-used sessions, may run into consistency issues in environments where multiple servers are used.

Forward secrecy and middleboxes

The second major change in TLS 1.3 is that non-forward secret cipher suites, including those that use static RSA key exchange, have been removed entirely. Cipher suites without forward secrecy have a vulnerability whereby, if the server’s private key is compromised, the attacker can passively decrypt sessions that were negotiated using that key, even if the sessions were captured long before the key was actually compromised. Forward secret cipher suites don’t have this problem; an attacker would have to obtain each session’s master secret in order to decrypt it.

This has major implications for enterprise network administrators that operate SSL-intercepting middleboxes, which are useful for intrusion detection, data loss prevention, email monitoring, and web filtering. Middlebox administrators can no longer simply ask server administrators to provide the server’s private key. Instead, they would have to obtain each session’s master secret.

The solution likely to be employed by TLS 1.3 middleboxes is to install special software on the endpoints (this could be either the client or the server) that exfiltrates the master secret to the middlebox on demand. This is a very different approach from that taken by many TLS 1.2 middleboxes, and administrators may have to upgrade or find a new vendor.

(It’s still possible for administrators to install a special root certificate on all client endpoints, and to terminate all connections at the middlebox, but this can be extremely resource-intensive, and distributing a custom root certificate may or may not be feasible.)

Other changes

TLS 1.3 makes a number of other changes, which are less impactful on the surface, but improve security moving forward. First, several unnecessary and potentially risky features, like TLS compression and session renegotiation (which have been associated with the CRIME and TLS Authentication Gap vulnerabilities, respectively), have been removed. The old session ID- and ticket-based session resumption mechanisms have been replaced with the new PSK mechanism (used in 0-RTT). Problematic cryptographic primitives like RC4, MAC-then-encrypt block cipher modes, SHA1 and MD5, and PKCS#1v1.5 padding are gone as well. In particular, the old CBC-based MAC-then-encrypt modes have been replaced with proper authenticated encryption (AEAD) modes like GCM.

Conclusion

TLS 1.3 improves TLS 1.2’s cryptographic primitives significantly, but introduces some new risks for web developers, and may force enterprise network administrators to rethink their SSL inspection strategy. So, if you’re a server administrator, should you upgrade? The first thing to realize is that TLS 1.2 isn’t being deprecated any time soon, and, if it’s deployed properly, it isn’t vulnerable to any serious known security issues. (In fact, TLS 1.3 deployments will need to support TLS 1.2 for a long time in order to interoperate with older client software.) The second thing to realize is that TLS 1.3 implementations are still in development; even OpenSSL’s TLS 1.3 support is still in beta. For now, most users will be just fine keeping their web servers up to date with the latest security patches; there’s little sense in running beta-quality software in order to support the latest security protocol.

But what about 0-RTT and middleboxes? We think it’s to early to say for sure how 0-RTT support will play out in server software and web frameworks. However, if you find yourself in a position to deploy TLS 1.3, we recommend disabling 0-RTT until a security assessment can help you determine whether replay attacks might pose a risk to your application. Middlebox administrators may be able to hang on to their TLS 1.2 middleboxes for the time being, but eventually TLS 1.3 adoption will force an upgrade, so check with your vendor to see whether they plan to support the latest protocol.

--

--