How does TLS 1.3 differ from TLS 1.2?

After a long drafting and review process, the completed version of TLS 1.3 has been published. What's different about TLS 1.3 compared to TLS 1.2? What effect will the new version have?

Usually, the difference between version 1.2 and 1.3 of a software product or protocol isn't that great, but in the case of Transport Layer Security (TLS) version 1.3, it's vastly different from its predecessor when it comes to security, performance and privacy.

It has taken 28 drafts and four years of extensive debate and testing by the Internet Engineering Task Force to approve the latest version of probably the most important -- and certainly the most used -- security protocol today. Its predecessors, Secure Sockets Layer, TLS 1.0, TLS 1.1, as well as TLS 1.2, which was published back in 2008, have been plagued by weaknesses that have enabled attacks such as Freak, Logjam, Drown and Beast, as well as the mass surveillance of encrypted internet traffic by government agencies.

Although TLS 1.2 can be deployed securely, various attacks have exploited optional parts of the protocol and the outdated algorithms it uses. To ensure TLS 1.3 doesn't encounter similar issues, it only includes support for cryptographic algorithms with no known vulnerabilities, like the elliptic curve Diffie-Hellman key exchange, Authenticated Encryption with Associated Data ciphers and HKDF.

By removing support for exploitable options and older, insecure protocols, ciphers and algorithms, such as Cipher Block Chaining Mode, Triple DES and RC4 stream cipher, TLS version 1.3 is not vulnerable to attacks such as Freak, Logjam and Poodle. It has been designed in cooperation with the academic security community, including formal verification of the various aspects of the protocol by multiple independent groups.

TLS 3.0 also eliminates any negotiation over what form of encryption communicating parties are going to use, thus avoiding the risk of downgrade attacks. The initial connection is a statement from the client saying what it plans to access. The server then provides an encryption key and the client provides a session key and the connection takes place.

With TLS 1.2 and earlier versions, a hacker who discovered a server's private key could use it to decrypt previous network traffic to and from the server. With the forward secrecy in TLS 1.3, there's no longer a single secret value that will decrypt multiple sessions. Instead, TLS 1.3 uses the ephemeral Diffie-Hellman key exchange protocol, which generates a one-time key that's used only for the current network session, meaning a hacker would have to discover the unique key for each session.

With respect to performance, new TLS 1.3 connections cut out an entire round trip from the connection establishment handshake, making HTTPS connections more efficient and less resource-hungry. This is great for websites with heavy traffic and mobile users, as it reduces latency and requires less CPU usage.

By forcing the use of new encryption and the elimination of unnecessary initial communications, TLS 1.3 can deliver faster, more secure communication over the internet.

TLS 3.0 also provides additional privacy for data exchanges by encrypting more of the negotiation handshake to protect it from eavesdroppers. In previous versions of TLS, the entire handshake was in the clear, which leaked information, including both the client and server's identities -- data that was often used for traffic analysis.

One feature that speeds up TLS 1.3 connections that security teams need to be aware of is the use of 0-RTT Resumption. This allows two computers that previously completed a TLS 1.3 handshake to store each other's information and use old keys for future connections. The purpose of this is to speed up repeat connections, and it is particularly valuable for mobile networks, but if an attacker manages to gain access to 0-RTT Resumption information and physical access to a device, they could spoof a connection.

The extensive collaboration and testing that have gone into this protocol means it is relatively painless to implement. Users will not have to make any changes, as most modern web browsers and applications already support TLS 1.3. It has been designed as a drop-in replacement for TLS 1.2 -- it uses the same keys and certificates, and clients and servers can automatically negotiate TLS 1.3 when they both support it. This way, network administrators who keep their servers up to date only need to ensure that any settings use TLS 1.3 as the default.

Being able to securely send information over the internet is critical for the modern world, and TLS 1.3 can ensure transmitted information isn't tampered with, forged or read by anyone other than the sender and receiver. By forcing the use of new encryption and the elimination of unnecessary initial communications, TLS 1.3 can deliver faster, more secure communication over the internet.

Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)