Google Chrome Drops Support for TLS 1.0 and 1.1

The latest stable release of Google Chrome, version 72, has removed support for the aging 1.0 and 1.1 versions of TLS, as well as for the problematic HTTP-based Public Key Pinning protocol and FTP resources.

The Transport Layer Security (TLS) protocol is the successor of SSL and is the foundation of HTTPS, the protocol used to encrypt communications between websites and end users. TLS is also used for securing other transmission protocols, such as POP3S, IMAPS and SMTPS, which are used for sending and receiving emails.

TLS 1.0 and 1.1 are now 20 and 13 years old, respectively, and they’ve been plagued by many vulnerabilities over time that could be used to break the security of HTTPS connections. They also rely on the MD5 and SHA-1 hashing algorithms, which are now both cryptographically broken. TLS 1.3, the fastest and most secure version of the protocol was standardized last year and is still being rolled out.

Despite the issues of TLS 1.0 and 1.1, which can be mitigated to some extent, many HTTPS-enabled websites still support them for backward compatibility with older browsers. According to the SSL Pulse project, which tests the 150,000 most popular HTTPS-enabled websites on the internet every month, around 71 percent of them still support TLS 1.0 and 79 percent TLS 1.1, alongside the newer TLS 1.2 and 1.3 versions.

In October, Google, Apple, Microsoft and Mozilla all announced plans to deprecate support for TLS 1.0 and 1.1 in their respective browsers. Google said at the time that the removal will happen in Chrome version 72, which was released this week.

The recommendation for website administrators is to use TLS 1.2 or 1.3, to prioritize ECDHE and AEAD-based cipher suites in their TLS configurations—ECDHE_RSA_WITH_AES_128_GCM_SHA256 is best—and to use SHA-2 hashing. Making these changes doesn’t require replacing the existing SSL/TLS certificates on servers.

Chrome 72 for desktop also removed support for HTTP-Based Public Key Pinning (HPKP), a security mechanism standardized in 2015 that can be used to prevent the abuse of mis-issued certificates to impersonate websites. The mechanism, also known as dynamic certificate pinning, allows websites to tell visiting browsers which certificates they should expect from them or which CAs are allowed to issue certificates for those websites.

This information is transmitted through a response header and gets pinned inside browsers. On subsequent visits to the site, those browsers will refuse to establish a connection if the presented certificate doesn’t match the pinned information.

HPKP was introduced in response to DNS hijacking attacks wherein hackers were able to obtain fraudulent yet technically valid certificates for high-profile websites by tricking or compromising CAs.

The problem is that configuring HPKP correctly is not easy and website administrators can accidentally render their websites inaccessible to previous visitors. Even worse, if the web server is compromised, attackers can modify HPKP headers intentionally and the only way to recover is to wait for the pin to expire inside browsers, which can take months, depending on configuration.

Google Chrome also has another feature called static pinning which uses a hard-coded list of pinned certificates that website owners submitted to a service run by Google. This feature is still present, but has been flagged for future removal once Chrome begins accepting only TLS certificates that have been published by CAs in Certificate Transparency (CT) logs.

Most CAs have already started using CT for all of their newly issued certificates and this will allow for fraudulent certificates to be detected and blacklisted automatically, making static pinning obsolete.

Finally, Chrome 72 will no longer render files served via FTP (File Transfer Protocol) inside the browser and instead will offer those resources for download.

“FTP is a non-securable legacy protocol,” the Chrome developers said on their feature tracker. “When even the linux kernel is migrating off of it, it’s really time to move on. One step toward deprecation and removal is to deprecate rendering resources from FTP servers and instead download them. We’ll still generate directory listings, but any non-directory listing could be downloaded rather than rendered in the browser.”

Lucian Constantin

Lucian Constantin

Lucian has been covering computer security and the hacker culture for almost a decade, his work appearing in many technology publications including PCWorld, Computerworld, Network World, CIO, CSO, Forbes and The Inquirer. He has a bachelor's degree in political science, but has been passionate about computers and cybersecurity from an early age. Before he chose a career in journalism, Lucian worked as a system and network administrator. He enjoys attending security conferences and delving into interesting research papers. You can reach him at [email protected] or @lconstantin on Twitter. For encrypted email, his PGP key's fingerprint is: 7A66 4901 5CDA 844E 8C6D 04D5 2BB4 6332 FC52 6D42

lucian-constantin has 298 posts and counting.See all posts by lucian-constantin