TLS 1.3 is the latest transport layer communications security protocol for traffic between web browsers and servers.

For twelve years, the standard internet encryption has been Transport Layer Security (TLS) 1.2. Following its roots takes you back to the first version of the Secure Sockets Layer (SSL) protocol, which was developed in 1995 by Netscape but never released due to it being riddled with security vulnerabilities. SSL 2.0 and 3.0 quickly followed and were released but also had their issues.

The first iteration of TLS – 1.0 – was based upon SSL 3.0, and was published in 1999 by the Internet Engineering Task Force (IETF). While there are differences, the two protocols share enough similarities that SSL and TLS are often used interchangeably.

In 25 years, we’ve seen the protocols improve, but it’s been incredibly slow going. That’s because TLS, and SSL before it, are both formed on open standards and, in order for them to effectively evolve, they need to be adopted en masse. Device manufacturers, web browser providers, applications (Facebook and its servers, for instance), all have to adopt to ensure there aren’t gaps – but that involves millions of moving parts.

That’s why, despite TLS 1.3 being around since 2018 and offering greater security that TLS 1.2, the latter that remains the de facto standard. There is a big push from US organizations for its widespread adoption, but it’s going to take time.

Other standard protocols that continue to be used are the Domain Name System (DNS) and Hypertext Transfer Protocol (HTTP). The former is often referred to as the “phonebook of the internet’”and is effectively a huge database filled with IP addresses. The latter is used to send data over the connection. Both naturally use clear text, meaning any man-in-the-middle (MITM) attack can quite easily identify what sites a user is attempting to access.

Why the push for TLS 1.3?

TLS provides secure communication between web browsers, end-user facing applications and servers by encrypting the transmitted information, preventing eavesdropping or tampering attacks. The full process relies on two types of encryption: asymmetric, which requires a public and private key, and symmetric, which uses a shared key.

Asymmetric encryption is used during the “handshake”, which takes place prior to any data being sent. The handshake determines which cipher suite to use for the session – in other words, the symmetric encryption type – so that both browser and server agree. The TLS 1.2 protocol took multiple round trips between client and server, while TLS 1.3 is a much smoother process that requires only one trip. This latency saving shaves milliseconds off each connection.

Another characteristic of TLS 1.3 is that it can operate alongside DNS over HTTPS (DoH). This protocol sees the URL / IP request sent across an encrypted Hypertext Transfer Protocol Secure (HTTPS) connection and hides it within regular traffic, meaning snoopers can’t identify the requests. Therefore, they don’t know what sites the individual is attempting to access and also can’t tamper with the connection.

It is also seen by some as the solution to mass censorship in certain countries, as ISPs would be unable to block access to particular sites. However, this ability is actually hindered by shortfalls elsewhere and those claiming it have been criticised for providing individuals with a false sense of security.

How cybercriminals are exploiting the gaps in adoption

When fully adopted, TLS 1.3 will make the internet a safer place but until that happens, the fractured uptake is empowering the bad guys.

One attack that keeps rearing its ugly head is the “Bleichenbacher”. Named after a Swiss cryptographer, the attack variant has seen numerous versions which target the RSA decryption algorithm. While TLS authors have attempted to make it harder to uncover the RSA decryption key, each new Bleichenbacher variant manages to do it. As such, any device that uses TLS-based features is vulnerable. TLS 1.3 attempts to limit RSA usage but ad hoc adoption means downgrading to TLS 1.2 often takes place and attacks are rife.

There are also many that argue that DoH is actually weakening cybersecurity efforts, with more and more botnets using its encryption capability to bypass traditional DNS measures and other legacy technology. Encrypted requests mean that they fly under the radar of typical measures and prevent corporate cybersecurity tools that rely on local DNS servers and DNS monitoring from blocking certain access requests. This could potentially result in employees landing on malware-ridden sites.

What should companies be doing to protect themselves?

Businesses must take steps to ensure all of their devices, servers and everything under their control supports TLS 1.3. However, the likely downgrading to 1.2 when dealing with external points means the vulnerabilities of the older protocol still need to be managed. Fortunately, 1.3 has an in-built feature that flags when this reversion has taken place so that companies can address the situation.

Going deeper, companies need to ensure network monitor tools are set up to cope with the added encryption TLS 1.3 brings and how it may be used by attackers to gain an advantage. Typically, companies would use a MITM middlebox which would analyze requests made in TLS 1.2 and decide whether a request was genuine or not before issuing the relevant certificate. But this process is impossible with 1.3 as it encrypts the aspects that were used by the middlebox to judge requests. As such, businesses should look to strengthen endpoint security to help mitigate initial intruder access onto networks, while also ensuring that security teams receive up-to-date response training and access to real-time intelligence to identify and analyze attacks.

The move to TLS 1.3 will reduce latency and remove the vulnerabilities present in TLS 1.2. But businesses can’t simply adopt it, then sit back and relax. With older protocols still widely used and their vulnerabilities exploitable, organizations must enhance endpoint security measures and the expertise of their security teams.