Moving the Internet to TLS 1.3, asap

Moving the Internet to TLS 1.3, asap

You do know that WPA-2 is fundamentally flawed? And you know that some versions of TLS are weak from a security point-of-view?

Imagine that a new building material had been created which was stronger than all previous ones? Or where it was found that a previous building material had flaws? Civil engineers would be really pushing it out. But with TLS 1.3 and WPA 3? Where the great voice of the cybersecurity industry pushing forward to fix the flaws of the past? A little quiet, perhaps?

So before you read on, you might want to read a basic introduction to TLS 1.3:

In terms of adoption, it has risen to around 30%, but still around 40% of Web sites on the Internet are support TLS 1.0 and TLS 1.1. The impact of turning-off TLS 1.0 is likely to be minimal, and would significantly reduce the exposure to attacks. Here is the results from 11 Sept 2021:

For many sites, TLS 1.2 is still the “best” protocol version they support (50%), with around 48% offering TLS 1.3:

Key scheduling

TLS 1.3 brings quite a few enhancements such as 0-RTT (Zero Round Trip Time), and drops the RSA key exchange method (and where a hack of the private key of a server could release all of the keys used with tunnels in the past). It also enhances the key scheduling using both ECDH (Elliptic Curve Diffie Hellman) and a PSK (Pre-shared Key). So, let’s take a little dive into TLS 1.3 (RFC 8446) and look at Section 7.1:

Within TLS 1.3 we use secrets to create the key. In TLS 1.3, the key for the symmetric key tunnel uses HKDF (HMAC Key Derivation Function) with a PSK (Pre-shared key) and the results from the ECDH key handshake:

Basically we use the HKDF method to take the secrets and convert into a key. For the PSK, we take some randomization values from the Client Hello (sent from the Client to the Server in the TLS handshake), and then from the ECDH exchange:

The secrets stored are defined on the left-hand side, and the parameters in the Client and Server hellos are shown on the right-hand side. The parameters on the right-hand side allow both the client and server to derive the same key. With this method, we can now implement 0-RTT, and we do not need to negitate a connection between a given client and server.

Here is an example of extracting the PRK, hash, and info for “c e traffic” and “e exp master”):

and for the server:

Overall we are using the HKDF to generate the derived key:

Conclusions

For a faster and more secure Internet, we need to move to TLS 1.3. And here is my blufflers guide to WPA-3 — and which is a SIGNIFICANT improvement on the flawed WPA-2 version: