There are currently three versions of the TLS protocol in use today: TLS 1.0, 1.1, and 1.2.
TLS 1.0 was released in 1999, making it a nearly two-decade-old protocol. It has been known to be vulnerable to attacks—such as BEAST and POODLE—for years, in addition to supporting weak cryptography, which doesn’t keep modern-day connections sufficiently secure.
TLS 1.1 is the forgotten “middle child.” It doesn’t have any known protocol vulnerabilities, though does share support for bad cryptography like its younger sibling. In most software it was leapfrogged by TLS 1.2 and it’s rare to see TLS 1.1 used.
These versions are rarely used by clients, falling to single-digit percentages of all HTTPS connections made for many sites. Yet, of the 150,000 HTTPS-enabled sites monitored by SSL Pulse, 88% support TLS 1.0 and 85% support TLS 1.1.
It may seem obvious that it’s time to stop using these dated versions of the protocol that back HTTPS, but on the internet there’s a big difference between nearly dead and dead. This year a large number of websites and services are finally ending support for TLS 1.0 and 1.1 (including DigiCert).
Almost everyone reading this post—and in fact, most of the internet—is using TLS 1.2, the current latest version of the protocol (though TLS 1.3 is around the corner, more on that later). This is the only version of the protocol that is recommended by cryptographers and considered to be “modern.”
However, a small portion of users may not be ready for the switch due to outdated software. Despite being released in 2008, TLS 1.2 support was absent from some major platforms and browsers for some time. Internet Explorer didn’t support TLS 1.2 until 2013’s release of version 11; and Android versions prior to 5.0 (released 2014) only supported TLS 1.0, which represents nearly 18% of Android devices still in use today.
Measuring TLS protocol use across the internet is very hard. One good indicator is data from Cloudflare, which, as one of the world’s largest CDNs, has good visibility into things happening at internet-scale. They recently shared about 11% of traffic on their network uses TLS 1.0 (with only a tiny portion (0.38%) using TLS 1.1).
What is even harder to determine is what percent of traffic comes from the consumer software used by organic, squishy humans on the internet, and what percent is coming from other computers running web servers, API endpoints, and other software.
The existence of TLS 1.0 and 1.1 on the internet primarily acts as a security risk—these protocols are almost universally supported by servers, but their use by clients is closer to the inverse. Clients that need to use these versions are suffering from their shortcomings. The rest of the internet is vulnerable to downgrade attacks (which force users onto weaker versions of TLS to exploit the known vulnerabilities) for almost no practical benefit. For most of these servers, older versions of TLS are likely left on “just in case,” or someone forgot to turn them off when they turned on newer versions.
A major change that is finally spurring the deprecation of TLS 1.0 is an upcoming deadline in the PCI (Payment Card Industry) standards. These standards cover security practices related to handling credit cards and apply to many businesses. Starting June 30, 2018, websites will need to stop supporting TLS 1.0 to remain PCI compliant.
The following version (TLS 1.1) is seen as a minor incremental upgrade. While PCI standards will still allow TLS 1.1 after June, many websites are choosing to deprecate both at the same time due to the historically low adoption of this version.
What does this mean for the average browser user? This change will be mostly invisible to them. The vast majority of websites already support TLS 1.2 and any sufficiently modern browser (almost anything release in the last five years) also supports TLS 1.2, and opts to use the newest supported version.
This deprecation will primarily affect non-browser software, APIs, and other internet infrastructure. Older versions of development tools which don’t support TLS 1.2, such as curl, are still widely in use—either directly by developers or as dependencies bundled into other software. Github is one of the first major services to turn off TLS 1.0 and 1.1. They made the change in February, which revealed a number of breakages in developer tools.
DigiCert will be disabling TLS 1.0 and 1.1 for all our services, including our website and API, on April 1st. (We promise that isn’t an April Fool’s joke.)
Many major websites and services have announced that they are also ending support later this year. KeyCDN will end support for TLS 1.0 and 1.1 on March 30th, as will Cloud.gov. Fastly will stop supporting TLS 1.0 and 1.1 on May 8th. Cloudflare will disable TLS 1.0 and 1.1 support for their API on June 4th. Microsoft’s Office 365 will only support TLS 1.2 starting October 31st. These are only a few major examples.
As the internet finally winds down support for TLS 1.0, the next generation of the secure protocol is about to be finalized. TLS 1.3 has been in the drafting process at the Internet Engineering Task Force for quite some time, and was recently approved at the IETF 101 meeting in London. The final editorial review process will likely take a few months, and then deployment will occur slowly as client and server software adds support.
TLS 1.3 brings a number of major improvements, including a faster handshake that will speed up connections, and the simplification of supported cryptography which will reduce complexity in the protocol and removes less secure ciphers.
Draft versions of TLS 1.3 have been supported by some major providers, like the Chrome browser and Cloudflare for quite some time. Recently, Cloudflare shared that 2% of connections on their network are already using TLS 1.3. When TLS 1.3 becomes an official RFC, we will see adoption of this new protocol version jump as major software packages like OpenSSL add support.