More than 850,000 websites still rely on the outdated TLS 1.0 and TLS 1.1 protocols that are scheduled to be blocked by the majority of web browsers this month. These older versions of the Transport Layer Security protocol, which date back to 1999 and 2006, are vulnerable to numerous practical attacks that have been resolved in later versions. Among the sites still using these outdated setups are major banks, governments, news, and telecoms companies. Big and small alike, such websites are about to be derailed by full-page browser warnings, with the added prospect of getting blocked entirely later on.

This all comes despite more than a year’s notice. Back in late 2018, the four largest browser vendors — Mozilla, Google, Apple, and Microsoft — jointly announced the deprecation of TLS 1.0 and 1.1, with support to be removed from their browsers in March 2020 or shortly thereafter. But a number of notable sites have not heeded these warnings, and have so far failed to switch to a version of TLS more modern than 1.0.

Included in the list is Huawei, which is already under fire for its less than reassuring security practices. But it’s not just Huawei that’s letting TLS 1.0-only servers slip through the cracks — the UK’s largest mobile network, O2, uses a TLS 1.0-based redirect services on https://o2.co.uk. Governmental websites are also no exception, including the South Africa Justice department, justice.gov.za, and the California Tax Service Center, taxes.ca.gov. Usage of TLS 1.0 is also particularly prevalent on less popular sites or internal services — places where browser security warnings may go unnoticed for some time.

The first version of the Transport Layer Security protocol, or TLS, was introduced by the IETF as an upgrade of the Secure Sockets Layer (SSL) 3.0 protocol developed by Netscape in 1996. These protocols are intended to protect systems communicating over untrusted networks from impersonation, eavesdroppers and message tampering. However, since its initial release, multiple cryptographic attacks against the 21-year-old protocol have been discovered, targeting broken ciphers, weak key exchange algorithms, and information leaks resulting from side-channel attacks. Some of these attacks include, BEAST, POODLE, LUCKY 13, and SWEET 32. TLS 1.1, standardised in 2006, addressed many of the issues in TLS 1.0, but was further improved upon by TLS 1.2 in 2008, little more than two years later. Despite being a later protocol, only 9,158 of the sites visited by Netcraft offer TLS 1.1 as their latest protocol. Today, TLS 1.0 and 1.1 are both considered insecure.

In the run-up to the ultimate TLS 1.0 and 1.1 shut-off, many browsers have been presenting visitors to such sites with UI cues indicating the usage of these insecure protocols. Chrome 79, for instance, started using the words "Not Secure" in the address bar, and Firefox shows a yellow warning triangle.

Some sites use TLS 1.0 servers purely to handle redirects from one domain to another. https://telecomitalia.it is one example, which simply redirects to www.tim.it. Despite a collective effort by web browsers to indicate the usage of insecure TLS 1.0 connections to visitors, setups like these have been exceptionally subtle, and practically impossible for the average user or site operator to detect, as they are directed away from the TLS 1.0-only site before a browser warning is ever shown. HTTPS servers such as these provide an example of a case where TLS is used more for the sake of interoperability than actual security. Nonetheless, with browsers about to break connections to TLS 1.0 sites, these kinds of sites are like a ticking time-bomb, as the redirects won’t work following browser updates, potentially leading visitors to believe such websites are down, or, at the very least, untrustworthy.

Another edge case where browsers have previously struggled to highlight the usage of outdated TLS involves cross-origin APIs and resources. Parts of certain advertising networks are one such example, where scripts and iframe content are hosted for inclusion within other websites. Although some of these resources are served exclusively over TLS 1.0, browsers typically make no indication of this in their normal security UIs. But these resources will also be blocked by browsers soon, breaking any functionality they are meant to provide. Although many of us won’t mind seeing fewer ads, in more extreme cases missing scripts and unreachable APIs can cripple a website, preventing it from working entirely.

The use of TLS 1.0 on e-commerce websites as a measure for protecting user data has been forbidden by the Payment Card Industry Data Security Standard since June 2018, and many websites have already migrated. However, PCI DSS never placed such requirements on systems where HTTPS or TLS are not used as a security measure (and indeed does not hold authority over all websites in general), so some website operators may have felt content with inaction. But browsers are the gate-keepers to the web, and hold a unique kind of authority over all websites. They, unlike security standards bodies, are in a position of power to enact change, and have regularly exercised such power. Slow-acting websites have frequently been caught out by browser action in the past, such as when browser interfaces began highlighting the usage of SHA-1 and penalising websites for using plaintext HTTP. Browsers make no exceptions — it doesn’t matter whether you use HTTPS to protect customer data, boost your status among search engines, or simply use HTTPS for the sake of HTTPS — if you don’t follow their rules, your sites are going to break.

But why is it taking so long for some to make the jump to TLS 1.2, the minimum safe version of TLS? Despite TLS 1.1 becoming a standard in 2006, and TLS 1.2 in 2008, they did not initially attract much attention, with many people at the time believing that the level of security provided by TLS 1.0 was simply good enough. It wasn’t until later when the flaws with SSL 3.0 and TLS 1.0 began to be fully realised that the web community began to push for adoption of TLS 1.1 and TLS 1.2. TLS 1.2 didn’t gain widespread browser support until five and a half years after its standardisation, when Firefox 27 added support in 2014 — the last major browser to do so. But operating systems and server software also took some time to catch on, and aren’t as readily upgrade-able. Even today, end-of-life legacy systems, such as RHEL 5, Debian 6 (Squeeze), and Windows Server 2003, which never supported TLS 1.2, are still used on the web.

Removing client-side support for these older protocols is the most effective way of ensuring that their associated vulnerabilities can no longer pose any risks. The web is a continually evolving ecosystem, and the most recent version of TLS, version 1.3 standardised in August 2018, has already been implemented by most major browser and server vendors. The quick adoption of TLS 1.3, compared to TLS 1.2, can be owed not only to improvements in security, but also performance.

You can find out whether your site is running an up-to-date version of TLS by checking out its Netcraft Site Report.