Web encryption is about to see a major improvement with the finalization of the TLS 1.3 protocol, which brings enhanced security as well as faster loading pages. Cloudflare, a popular web company that offers DDoS protection and CDN services, among other things, said that it has already implemented TLS 1.3 for all of its customers. However, it’s now waiting on browsers to support it as well so that everyone can use it.
The TLS 1.2 protocol, which was the last version of TLS to be standardized in 2008, has started to show its age. If it’s configured correctly, it can be secure, but not everyone tends to configure it properly, so attacks against websites’ encryption can still succeed. TLS 1.3 aims to be simpler to implement and configure by web developers, while also increasing both security and the performance of encrypted connections.
Stronger Security
Over the past couple of years, we’ve seen multiple attacks against web encryption that take advantage of the fact that web browsers and servers still support '90s-era protocols and algorithms, even if they don’t use them by default and prioritize the stronger options. However, sophisticated attackers can “downgrade” the connections to the insecure options. Then, they are able to eavesdrop on users’ communication with the website, or inject malware into the connection.
TLS 1.3 strives to get rid of all of unnecessary and broken encryption options that are known to be insecure. Developers won’t be able to turn on insecure cryptography, even if they wanted to.
Cloudflare enumerated the list of broken cryptography that has been eliminated from TLS 1.3:
RSA key transport — Doesn’t provide forward secrecyCBC mode ciphers — Responsible for BEAST, and Lucky 13RC4 stream cipher — Not secure for use in HTTPSSHA-1 hash function — Deprecated in favor of SHA-2Arbitrary Diffie-Hellman groups — CVE-2016-0701Export ciphers — Responsible for FREAK and LogJam
Perhaps the most interesting change here is the elimination of RSA encryption. RSA isn’t insecure per se (at high enough key sizes), but unlike elliptic curve cryptography (ECC), it can’t provide forward secrecy (key rotation), which makes it especially vulnerable against state sponsored attacks that try to steal the encryption keys.
This is also perhaps the first sign that the IETF organization, which is in charge of standardizing the TLS protocol, is making good on its 2014 promise to fight pervasive surveillance with new security protocols.
Faster Loading Times
The streamlining of the TLS 1.3 protocol makes it easier to configure for developers, but it also increases its performance. Without good enough performance, HTTPS encryption wouldn’t be adopted by as many websites as it is now. Netflix, for instance, held out on using HTTPS encryption for its video streaming for as long as possible, and until it could find a more efficient way of using encryption.
Netflix is working with billions of hours of video that need to be transmitted over encrypted channels, where the overhead of encryption may make a more significant impact. However, most websites deal with much lighter workloads, so the impact is much smaller. Still, increased performance is always welcome, especially if it can eliminate some objections from those still holding out on adopting it.
The biggest issue TLS 1.3 is trying to solve, which will positively affect all websites, is relatively high latency for websites that are accessed by users who are long distances away, such as across oceans or continents. According to Cloudflare, a message can take 200ms to get from Sydney to New York and back, which is a long-enough lag that it's noticeable by humans. Add another 100-200ms when the user connects from a 3G or 4G wireless device, and the slower loading time for a web page becomes even more noticeable.
Encryption adds its own latency. To send a message to an encrypted site, you first need to establish shared cryptographic keys. The process is called a cryptographic handshake, and it needs to send messages back and forth between the browser and the website.
With TLS 1.2, two such round-trips are needed, but with TLS 1.3, only one is necessary, thus cutting the encryption latency in half. “Zero round-trips” (0-RTT) will also be supported in TLS 1.3 for when the user revisits the same site. Cloudflare said it will support TLS 1.3 0-RTT in the coming weeks.
TLS 1.3 should be finalized at the end of the year, but Chrome Canary and Firefox Nightly have already started to support the current, mostly done, version of the protocol. Free and Pro customers of Cloudflare can enable it in their dashboards, but only browsers that support TLS 1.3 will be able to experience it. As it lands in the stable version of Chrome, Firefox, and other browsers, more users should be able to experience a faster and more secure web.
