Microsoft, Google Take on Obsolete TLS Protocols

Microsoft plans to disable older versions of the Transport Layer Security (TLS) protocol, the ubiquitous communications encryption used to protect information sent over networks and the Internet. While businesses and users will be able to re-enable the protocols if they need backward compatibility to continue using a critical application, companies should be migrating their systems to TLS v1.2 or 1.3, Microsoft stated in its latest guidance.

Starting this month, the company will disable TLS v1.0 and v1.1 by default in Windows 11 Insider Preview, followed by a broad deactivation on future Windows versions.

"Over the past several years, internet standards and regulatory bodies have deprecated or disallowed TLS versions 1.0 and 1.1, due to a variety of security issues," Microsoft stated in another advisory. "We have been tracking TLS protocol usage for several years and believe TLS 1.0 and TLS 1.1 usage data are low enough to act."

The planned switch comes six months after Google and its Chromium Project suggested that TLS certificates should have a maximum lifespan of 90 days , less than a quarter of the current maximum valid period of 398 days.

The Transport Layer Security (TLS) protocol — and its predecessor, Secure Sockets Layer (SSL) — have become the standard way to protect data in transit on the Internet. Yet weaknesses in SSL and the earlier versions of TLS have prompted technology companies and organizations, such as the Mozilla Foundation, to push for the adoption of the more secure TLS versions. The push for faster expiration of TLS certificates will also prompt companies to automate their certificate infrastructure, leading to better security agility, the Chromium Project stated in its March proposal to reduce certificate lifetimes.

"Reducing certificate lifetime encourages automation and the adoption of practices that will drive the ecosystem away from baroque, time-consuming, and error-prone issuance processes," the group stated. "These changes will allow for faster adoption of emerging security capabilities and best practices, and promote the agility required to transition the ecosystem to quantum-resistant algorithms quickly."

Time to Move to TLS 1.3

Companies should first inventory their TLS endpoints and collection of certificates and identify other technical components. Because of the move toward shorter lifetimes for certificates, automated management of keys and certificates is required, says Muralidharan Palanisamy, chief solutions officer for AppViewX.

"An automated solution can continuously scan your hybrid multicloud environments to give you visibility into your crypto assets and maintain an updated inventory to find expired and weak certificates," he says. "Full certificate life cycle management automation enables certificates to be reprovisioned, auto-renewed, and revoked."

The move to TLS 1.3 is already underway. More than one out of every five servers (21%) are using TLS 1.3, according to an AppViewX report based on Internet scans. The newer technology has huge performance benefits with zero round-trip time key exchanges and stronger security than TLS 1.2, offering perfect forward secrecy (PFS), Palanisamy says.

Many organizations use TLS 1.2 internally and use TLS 1.3 externally.

The move to such ubiquitous encryption is not without its downsides. Organizations should expect that — driven by the broad adoption of TLS 1.3 and DNS-over-HTTPS — network traffic will no longer be able to be inspected in the future, David Holmes, principal analyst at Forrester Research, stated in a report on maintaining security visibility in an encrypted future.

"As these changes gain momentum, security monitoring tools will be blinded to the contents and destination of traffic and unable to detect threats," Holmes wrote. "The network will be darker than it’s ever been. Both the security practitioner and vendor communities are actively creating solutions that can bring visibility back to the network."

POODLE, Heartbleed, and Other Rare Breeds

In general, TLS vulnerabilities are a fairly esoteric threat, with many theoretical weaknesses but few attacks seen in the wild, according to Holmes. Attackers rarely target TLS issues because attacking encryption infrastructure is generally extremely complicated, requiring a great deal of sophistication.

Yet when a vulnerability is found, the implications can be pervasive because the TLS encryption infrastructure is ubiquitous. In 2014, the discovery of the infamous Heartbleed vulnerability in the OpenSSL library resulted in a race to patch major servers before attackers could exploit the issue to steal sensitive data from servers. The same year, the discovery of a vulnerability in Secure Sockets Layer (SSL) v3.0 allowed a machine-in-the-middle attack — the most well-known example being the proof-of-concept code dubbed the Padding Oracle on Downgraded Legacy Encryption (POODLE) attack.

"The POODLE attack was a critical vulnerability in SSLv3 — the precursor to TLS 1.0 — and its discovery caused the Internet to disable that protocol basically overnight — within a matter of months, which is shockingly fast," Holmes says.

While TLS threats are serious, often they are a sign that an application or server is out of date, which often means that a significant number of easier-to-exploit vulnerabilities are present, so attackers will typically turn their attention there.

TLS 1.0 and 1.1 continue to be supported because a small number of mission-critical apps that are difficult, if not impossible, to patch rely on the communications protocol.

"Many of these simply can’t be upgraded — or they would have been already," he says. "Think about custom applications written decades ago for a specific device that runs only in a handful of factories. The software teams that built those applications disbanded or retired long ago but the application still runs."