Web admins have about one month to upgrade

Websites that support encryption protocols no higher than TLS 1.0 or 1.1 have only a few weeks to upgrade before major browsers start returning ‘secure connection failed’ error pages.

Google, Apple, Microsoft, and Mozilla jointly agreed in October 2018 to deprecate the aging protocols by early 2020 – a move likely to throttle the traffic flowing to laggard sites yet to upgrade to TLS 1.2 and above.

Mozilla will likely be first to jettison support for TLS 1.0 and 1.1 – 21 and 14 years old, respectively – with the release of Firefox 74 on March 10.

Google Chrome 81, slated for launch on March 17, will disable support too, while Apple’s next Safari update is expected to land, with support for older encryption suites removed, by the end of the month.

Microsoft is expected to remove support for the moribund protocols from Edge 82 in April and Internet Explorer at around the same time.

Webmasters have been notified about the upcoming switch, for instance by advice to migrate issued within developer tools in Firefox 68 and Chrome 72, which were launched last year.

In December, Firefox 71 arrived with support disabled in Nightly mode to “uncover more sites that aren’t able to speak TLS 1.2”.

SSL Pulse’s latest analysis of Alexa’s most popular websites, conducted in February, reveals that of nearly 140,000 websites, just 3.2% fail to support protocols higher than TLS 1.0, and less than 0.1% have a ceiling of TLS 1.1.

Some 71.7% support a maximum of TLS 1.2, while the remaining 25% support the latest version, TLS 1.3.

According to these figures, then, 3.3% of sites could soon be returning ‘secure connection failed’ error pages to visiting surfers.

Formal deprecation

The Internet Engineering Task Force (IETF), the global guardian for internet standards, is formally deprecating both TLS 1.0 and 1.1.

The National Institute of Standards and Technology (NIST) says it is no longer practical to patch the protocols’ existing vulnerabilities, such as the POODLE and BEAST man-in-the-middle attacks.

The protocols neither support the latest cryptographic algorithms nor comply with today’s PCI Data Security Standards (PCI DSS) for protecting payment data.

While TLS 1.3, launched in 2018, is now the gold standard, TLS 1.2 is PCI DSS-compliant and remains in good standing despite being more than a decade old.

Both TLS 1.2 and 1.3 are supported by all major browsers. Both support the latest cryptographic cipher suites and algorithms, remove mandatory, insecure SHA-1 and MD5 hash functions as part of peer authentication, and are resilient against downgrade-related attacks like LogJam and FREAK.

Take action

Michal Špaček, developer at Report URI and Password Storage Rating, urges webmasters to take action “before it's too late”.

If they’re unsure about their site’s SSL configuration, he recommends using tools like SSL Labs Server Test and Mozilla Observatory.

If checks reveal that a websites fails to support at least TLS 1.2, how should webmasters proceed?

“The short answer is to check with their vendors,” Špaček told The Daily Swig. “The slightly longer (and maybe better) answer is to run recent encryption libraries (like OpenSSL) and servers (like Apache or Nginx)”, all of which support TLS 1.2 and TLS 1.3 - and the latter “might even be a one-line change in the supported protocols config option”.

He added: “You can also check what protocol is used to access the site in the browser devtools, Security tab.”

In a recent blog post, security researcher Scott Helme points out that “you don't necessarily have to remove support for these Legacy TLS versions, you simply have to make sure that you support at least TLSv1.2 for clients like Chrome/Firefox/Safari to be able to connect.”

In a message addressed to developers in September 2019 Mozilla engineer Martin Thomson said: “This is a potentially disruptive change, but we believe that this is good for the security and stability of the web,” noting “that the number of sites that will be affected is reducing steadily.”

READ MORE Chrome SameSite cookie change expected to result in ‘modest’ website breakage