TLS 1.0 Inches Closer to Full Retirement (Nearly a Decade Later)
Microsoft Azure has pushed back its TLS 1.0 and 1.1 end-of-life date to Aug. 31, 2025. This delay is another example of how long it takes to upgrade the protocols the internet runs on.
It’s been more than half a decade since websites were told to start migrating from the TLS 1.0 protocol due to its vulnerability issues (and 3+ years since TLS 1.0 and 1.1 were officially deprecated). But it’s taking longer than expected to fully switch from TLS 1.0/1.1 to TLS 1.2 as a minimum. What’s the holdup?
Moving the entire internet from these early protocols isn’t easy — many systems depend on them. We’ll examine why these real-world security upgrades, TLS 1.2 and 1.3, are taking so long and what exactly these changes entail.
Plus, the internet is beginning an even bigger (and more challenging) migration: moving SSL/TLS to post quantum cryptography. Lessons from the past can smooth our path to the future.
Let’s hash it out.
TL;DR: A Look at the Timeline of TLS Protocol Migrations
Here’s a quick overview of the timeline of when these Internet Engineering Task Force’s requests for comments (RFCs) were originally published and their current statuses:
- TLS 1.0 came out in 1999 as a replacement for SSL 2.0 and 3.0. It was published as RFC 2246 and was deprecated by RFC 8996 (published in June 2018) in March 2021.
- TLS 1.1 was released in 2006 as IETF RFC 4346. This protocol, meant to be a minimal upgrade to TLS 1.0, was also deprecated by RFC 8996.
- TLS 1.2 was released in 2008 as IETF RFC 5246 and has been in use since. It’s technically been obsoleted by RFC 8446, but it’s currently still the most widely used protocol.
- TLS 1.3 was published in 2018 as IETF RFC 8446. It’s still in use today, although it’s not as widely adopted as TLS 1.2.
Here’s a visual representation of the establishment of the TLS 1.0 and 1.1 protocols and the migrations from them:
A 90-Second Review: Why Migrating from TLS 1.0 & TLS 1.1 Is a Must
Let’s start with a quick review of why the shift to TLS 1.2 as a minimum is necessary (ideally, use TLS 1.3 instead):
- TLS 1.0 is old enough to get a break on car insurance. Launched 25 years ago, this protocol supports outdated and weak cipher suites that leave systems vulnerable to exploitation.
- TLS 1.1 was released in 2006 as a minor upgrade but was never fully adopted. The goal was to rectify some of the issues identified in version 1.0. However, TLS 1.1 also has issues (namely, its use of weak ciphers), which is why industry leaders have since deprecated both protocols.
- PQC algorithms don’t work with earlier protocols. While some TLS 1.3 implementations support quantum-resistant algorithms, the same can’t be said about TLS 1.2 or earlier protocols. According to NIST’s Migration to Post-Quantum Cryptography Quantum Readiness: Testing Draft Standards preliminary draft, PQC algorithms aren’t retrofitted to work with the 1.2 protocol.
What Are the Challenges of Migrating from TLS 1.0 and 1.1?
Think of moving from secure sockets layer (SSL) to transport layer security (TLS). Migrating from old internet security protocols is no small or easy task. The process is incredibly time-consuming and challenging, and we’re already nearly a decade into that process for TLS 1.0 and 1.1.
However, simply stating that these outdated standards need to be deprecated and actually transitioning every system, server, and other elements to eliminate these dependencies are two different things. For starters, there are many moving parts involved, some examples of which include:
- Standards and regulatory requirements (IETF, PCI DSS, NIST, etc.)
- Development libraries, frameworks, and services (OpenSSL, .NET, Microsoft, etc.)
- Devices and hardware components
- Web server software
- Content Delivery Networks (CDNs)
- Web hosting management software like cPanel, etc.
- Your organization’s internal network(s) and endpoint devices
- Semi-separate networks (e.g., banking, payment services, IoT, etc.)
Many of these parts require cascading changes — for example, software can’t be upgraded until the libraries it uses and the servers it runs on have been upgraded.
What if these protocols had critical vulnerabilities that couldn’t be patched? Would upgrading still take a decade? Things would likely be different. The migrations from both protocols would have been better prioritized and likely wouldn’t have been pushed to the back burner by some organizations. But it still would have taken a long time.
How Many Websites Still Use TLS 1.0/1.1?
As of May 2, 2024, Qualys’s SSL Labs SSL Pulse dashboard showed that 27.9% of surveyed websites still supported the outdated protocol. Slightly higher still (30%) still supported TLS 1.1. Compare this to TLS 1.2 (99.9%) and 1.3 (70.1%), which are supported by most websites.
Our smaller but more recent internal data set shows a similar story with only 23% supporting TLS 1.0 and 24% supporting TLS 1.1.
Why do browsers and operating systems support multiple protocols, even when some of them are outdated? Because some users rely on legacy systems that may not support the newer, more secure protocols. These companies would have some pretty irked customers and users if they suddenly just “pulled the plug” on supporting the older protocols.
Which Browsers Do and Don’t Support TLS 1.0 and 1.1
Using the Can I Use search tool, I checked the TLS 1.0 protocol to see which web clients, if any, still support it. Here’s a quick look at what I found:
Here’s a quick look at which browsers either fully or partially support the TLS 1.1 protocol and which ones don’t on various desktop and mobile platforms:
How to Tell Whether Your Browser Is Using an Old Protocol
Wondering which protocols your web client supports? Here’s a quick example of what came back when I tested my browser’s SSL/TLS capabilities using Qualys’s SSL Labs SSL Client Test tool:
This tool will also show you which strong and weak cipher suites your browser supports (listed in order of preference) and whether it supports TLS compression.
6 Examples of the Industry’s Migration Journeys
So, what’s the process of migrating away from TLS 1.0 and 1.1 look like? For some, it’s been a long journey that we’d either wished had gone a bit more smoothly or would like to see wrap up sooner than later:
- GitHub — My former colleague enlightened you about GitHub’s challenges while deprecating the two protocols in February 2018. It temporarily disabled TLS 1.0 and 1.1 for an hour as a precursor to its full shutdown of the protocols two weeks later. Unfortunately, those still using the protocols apparently didn’t get the message, and the official change over created some issues.
- Google Chrome — It was originally planned for Chrome version 72 but the browser officially began its move from TLS 1.0 and 1.1 to TLS 1.2 as a minimum by displaying a warning in Dev Tools. This warning shifted to displaying a full-page warning in Chrome 81, then Chrome 91; eventually, Chrome 98 made the error non-bypassable. However, it fully kicked the outdated protocols to the curb once and for all in Chrome 84.
- PCI DSS — The Payment Card Industry Data Security Standards (PCI DSS) implemented a June 30, 2018 deadline to disable all SSL protocols and TLS 1.0 in favor of TLS 1.1+. This replaced the earlier June 2016 deadline that got pushed back. The only exception for the mandatory change to TLS 1.1+ was for payment terminals that could be verified as “not being susceptible to any known exploits for SSL and early TLS.” Now, the PCI Standards Council (PCI SSC) recommends moving away from “early TLS” versions as security controls for everything else and strongly encourages the use of TLS 1.2.
- NIST — The National Institute of Standards and Technology, the standards body for U.S. federal agencies and contractors, has published multiple versions of SP 800-52 to migrate through the various TLS protocols. The latest, SP 800-52 Rev. 2, requires TLS 1.2 and support for TLS 1.3.
- Microsoft — As of Oct. 31, 2018, Microsoft deprecated TLS 1.0 and 1.1 support in its Office 365 services. While many Microsoft services and systems have migrated to TLS 1.2 or higher, others are taking more time. The company provides a list of the Microsoft Azure offerings that still support legacy TLS protocols.
Final Thoughts: A Few Tips to Help You Migrate Away From TLS 1.0 & 1.1
Removing TLS 1.0 and 1.1 dependencies is a must to eliminate security risks and compliance issues. Here are some of the ways you can do it within your organization’s ecosystem:
- Create a TLS migration plan. This document will outline the necessary steps to keep you on track and provide any specifics you might need to carry out the migration.
- Check your endpoint devices and servers for deprecated protocols. This includes SSL (any version), TLS 1.0, and TLS 1.1. On Windows Servers, you can check the Secure Channel (SCHANNEL) to see which protocols are supported.
- Scan your network traffic to identify any pre-TLS 1.2 protocols in use. You can do this using OpenSSL, NMAP, or a tool like WireShark for data packet capture and analysis.
- Check your apps for hard-coded outdated protocols. Analyze your web apps and software code for any hardcoded uses of any of these insecure protocols. Be sure to implement regression testing after disabling the outdated protocols.
- Update your software and web clients. You can’t run the newer protocols on systems and apps that haven’t been updated since the TV show “Firefly” got canceled.
- Communicate protocol changes to your users, employees, partners, and other stakeholders. Prepare them in advance by communicating about the changes to eliminate any protocols earlier than TLS 1.2. Keep them informed as needed throughout and after the migration.
Needless to say, kowtowing to the insecure protocol requirements of legacy systems is a surefire way for sensitive data to become breached.
Bad guys are always looking for a way into your network and systems. They want to get their hands on your data. Don’t give them the opportunity — eliminate vulnerable, outdated TLS protocols within your IT ecosystem now and save yourself the headaches later.
It’s not too early to start planning your migration to post-quantum cryptography…
Be the first to comment