Last week saw the formal publication of the TLS 1.3 specification as RFC 8446. It’s been a long time coming – in fact it’s exactly 10 years since TLS 1.2 was published back in 2008 – but represents a substantial step forward in making the Internet a more secure and trusted place.
What is TLS and why is it needed?
Transport Layer Security (TLS) is widely used to encrypt data transmitted between Internet hosts, with the most popular use being for secure web browser connections (adding the ‘S’ to HTTP). It is also commonly (although less visibly) used to encrypt data sent to and from mail servers (using STARTTLS with SMTP and IMAP/POP etc..), but can be used in conjunction with many other Internet protocols (e.g. DNS-over-TLS, FTPS) where secure connections are required. For more information about how TLS works and why you should use it, please see our TLS Basics guide.
TLS is often used interchangeably with SSL (Secure Socket Layers) which was developed by Netscape and predates it as an IETF Standard, but many Certification Authorities (CAs) still market the X.509 certificates used by TLS as ‘SSL certificates’ due to their familiarity with users. It should be noted though, that all versions of the SSL protocol are now obsolete whilst TLS 1.0 is deprecated and should not be used.
How is TLS 1.3 improving things?
TLS 1.3 offers a number of technical advantages such as a simplified handshake to establish secure connections, and allow clients to more quickly resume sessions with servers. This should reduce setup latency and the number of failed connections on poor links that is often used as a justification for maintaining HTTP-only connections.
Just as importantly, it also removes support for several outdated and insecure encryption and hashing algorithms that are currently permitted (although no longer recommended) to be used with earlier versions of TLS, including SHA-1, MD5, DES, 3DES and AES-CBC, whilst adding support for newer cipher suites. Other enhancements include more encrypted elements of the handshake (e.g. the exchange of certificate information is now encrypted) to reduce hints to potential eavesdroppers, as well as improvements to forward secrecy when using particular key exchange modes so that communications at a given moment in time should remain secure even if the algorithms used to encrypt them are compromised in the future.
How can I use TLS 1.3?
So we’ve established that TLS 1.3 is a good thing for the Internet. but how can people actually take advantage of it? Of course, both the client and server need to have the ability to support TLS 1.3 to take advantage of the improvements, but the good news is that developers, vendors and service providers have been actively working to implement it for some time now, and it’s already supported by a number of applications.
Starting with web browsers, Google Chrome (including the Android version) from version 67 onwards, and Mozilla Firefox from version 61 onwards, already have support for TLS 1.3 by default. The latest version (54) of Opera also supports it, although it needs to be specifically enabled.
Apple has already implemented draft support for TLS 1.3 in both MacOS 10.13 and iOS 11, although this also needs to be specifically enabled.
With respect to server-side applications, many of these utilise TLS libraries and several of the more popular implementations including OpenSSL 1.1.1, GnuTLS 3.5.x, Google’s Boring SSL and Facebook’s Fizz are already supporting TLS 1.3. This should allow the protocol to quickly and easily be added to many widely used server applications, and indeed a number of Internet services including Google, Facebook, Akamai and Cloudflare are already supporting TLS 1.3 from compatible clients.
Microsoft does not yet support TLS 1.3 on any of its operating systems or in the Edge and Internet Explorer browsers, preferring to wait until the specification was finalised. It should be noted that early implementations of TLS 1.3 have been based on various versions of the specification (of which there were 28 in all), so a shakeout period will be required to bring implementations up to full standard, but this is likely to be short given the significance and importance of this protocol.
So what can possibly go wrong?
Well it’s not really a problem with TLS 1.3 per se, but whilst it has a mechanism to negotiate TLS 1.2 connections to those devices that can only support that protocol, there are a significant number of older applications that can only support earlier versions of TLS. As use of TLS 1.3 becomes more widespread and secure connections become expected, many devices and applications that cannot be upgraded may no longer be usable. However, the question that must be asked whether it’s advantageous or reasonable to keep supporting older protocols (e.g. TLS 1.0 and 1.1) when they become obsolete and potentially insecure?
The 0-RTT feature that allows data to be sent earlier when resuming secure connections to enable performance comparable with unencrypted handshaking, has been identified as having a potential weakness with respect to replay attacks (see Section 8 of RFC 8446). Nevertheless, replay attacks can happen with earlier versions of the TLS as well, and applications already need to implement specific restrictions on the scope of requests. 0-RTT can also be optionally turned off, or similarly limited in scope if this is a concern for particular types of application, and some guidelines for this can be found in RFC 8446.
Last but not least, many organisations implement middle box solutions to inspect and monitor traffic that is traversing their networks, particularly organisation have have strong regulatory and compliance requirements, This may be used identifying unauthorised or malicious communications, malware, or for monitoring self-signed or fake certificates for example, but as TLS 1.3 changes the handshake behaviour and encrypts certain parts of this (e.g. the certificate information exchange), this may affect middlebox functionality, downgrade TLS connections, or even prevent connections being made entirely.
The issue was identified during testing of early implementations of TLS 1.3, and changes made to allow certain features of the TLS 1.2 handshake to be replicated even though these are not actually necessary for the functioning of the new protocol. In addition, it’s still possible to implement other workarounds such as terminating all connections at the middlebox or distributing custom root certificates that allow decryption of the traffic, with the caveat there are resource and administrative practicalities to consider.
It should be appreciated though, that TLS 1.3 has been introduced to address some of the potential and actual vulnerabilities of earlier versions of the protocol such as the Triple Handshake, BEAST, FREAK and Logjam attacks. Whilst TLS 1.2 is not inherently a poor or even insecure protocol, it does require careful configuration to ensure obsolete cipher suites with identified vulnerabilities are not used in conjunction with it. TLS 1.3 removes the need to make these decisions, and brings significant performance improvements which should ensure there are no longer any reasons to be using unencrypted connections in future.
What You can do!
TLS 1.3 is being deployed now in browsers and many other applications, and in many cases you can already use it by selecting a browser that supports it. We also encourage you ask your IT teams, server administrators and developers to ensure that your sites and services support it, so we can collectively build a more secure Internet!
The Internet Society supports making encryption the new norm on the Internet, and our Deploy360 programme is developing resources on how to implement TLS in different applications.
Further Information