The Beginning of the End for TLS 1.0/1.1/1.2

The Beginning of the End for TLS 1.0/1.1/1.2

So after nearly five years in the making and 28 drafts, the IETF (Internet Engineering Task Force) rolled out the TLS (Transport Layer Security) 1.3 standard an it is now pushing its way to the front of the queue [here]:

The rapid growth has been pushed by browser updates. Overall it fixes many of the recently discovered problems and improves performance (and also dumps legacy methods). A new feature — Zero-RTT (zero round trip time resumption) — has been introduced to speed up things, but could actually be opening up a whole lot of new vulnerabilities.

Forward secrecy

An important update is where static RSA and Diffie-Hellman ciphers have been removed, and where all of the public key methods are now forward secrecy (FS). With this a comprise of the long-term keys will not compromise any previous session keys. For example if we send the public key of the server to the client, and then the client sends back a session key for the connection which is encrypted with the public key of the server, then the server will then decrypt this and determine the session. A leakage of the public key of the server would cause all the sessions which used this specific public key to be compromised. FS thus aims to overcome this by making sure that all the sessions keys could not be compromised, even though the long-term key was compromised. The problem with using the RSA method to pass keys is that a breach of the long keys would breach the keys previously used for secure communications.

Another important concept is where is key is ephemeral. With some key exchange methods, the same key will be generated if the same parameters are used on either side. This can cause problems as an intruder could guess the key, or even where the key was static and never changed. With ephemeral methods a different key is used for each connection, and, again, the leakage of any long-term would not cause all the associated session keys to be breached. The problem with the Diffie-Hellman method is that the keys are not ephemeral, so we should avoid it in generating keys.

The answer is to use methods which support FS and which are ephemeral. Within SSL/TLS connections, such as for HTTPS accesses, we can use DHE (ephemeral DH) or Ephemeral Diffie-Hellman with RSA (DHE-RSA) to make sure we do not create the same key. But to support FS, we need a method such as Elliptic Curve Ephemeral Diffie-Hellman with ECDSA (ECDHE-ECDSA) as it supports both ephemeral and FS, and is thus robust against attacks.

Zero-RTT

There’s a good deal of setting up in an HTTPs connection, such as with a DNS lookup, the 3-way TCP handshake, the TLS handshake, and then the HTTP download of a page. Zero-RTT (Round-Trip Time) aims to cut down this overhead by remembering a previous connection and then restoring it. This latency can be a particular problem on mobile networks (where there is typically no caching of content). With Zero-RTT, HTTPs can have the same latency overhead as HTTP. Unfortunately, it leaves systems open to replay attacks, such as [here]:

The IETF final draft does identify the risks around a replay attack with:

Goodbye to Bleichenbacher’s Attack?

This version fixes many of the recent vulnerabilities, including ROBOT. With ROBOT we saw the Bleichenbacher’s attack [here] return, and which exposed many Web sites to attackers.

Say goodbye to plain old hellos

The TLS handshake involves a ServerHello being sent back from the server to the client, and which shows the details of the connection:

Within TLS 1.3 this ServerHello is now encrypted, which means that the negotiation of keys and ciphers can now be kept secret.

Key derivation functions

There are improved key derivation functions within TLS 1.3, and which builds on HMAC-based Extract-and-Expand Key Derivation Function (HKDF) in order to create keys from the given properties. These include a pass phrase and salt, and which creates an encryption key of a given length. You can try HKDF here.

Elliptic Curve support

The world of public key encryption has been moving greatly toward ECC (Elliptic Curve Cryptography), especially with the usage of Curve 25519 (as used in Tor, Bitcoin, and many other applications. TLS 1.3 now directly integrates ECC, as well as improving the methods it uses to generate ECC parameters.

Conclusion

Well. It’s a nip and a tuck, but watch out for 0-RTT, as researchers will be priming their tools to attack it. Overall, do you want speed or security … 0-RTT improves speed, but lowers security. Some are already criticising TLS 1.3 for slow-downs in networks, but this is likely to be caused by poor implementations of the new methods. If you can’t wait for it to be rolled out, the OpenSSL Project has integrated the methods into OpenSSL 1.1.1 (it’s an alpha version, so watch-out!).