PSA: Moving SHA-1 and 3DES in TLS to a fallback

26 views
Skip to first unread message

David Benjamin

unread,
Feb 18, 2020, 6:19:15 PM2/18/20
to blink-dev, net-dev, security-dev

Hi all,

 

To gather more accurate usage metrics, we'll be moving SHA-1 signature algorithms in TLS 1.2, and 3DES cipher suites, to a fallback connection beginning with Chrome 82.

 

This is not expected to break any sites, including those which rely on the obsolete algorithms, and we do not yet have a concrete removal timeline, so this is not an Intent to Deprecate. Nonetheless, we encourage sites to migrate off these algorithms and, more generally, ensure they are using a modern TLS configuration. Sites can use the DevTools security panel, or tools like SSL Labs or Mozilla’s SSL configuration generator, to evaluate or update their configuration.

 

Note this change means Chrome will appear to not support 3DES or SHA-1 in tools like SSL Labs, but both algorithms will be available on fallback. This means that, for security purposes, the algorithms must still be considered enabled. Previously, when browsers implemented a fallback in the early stages of the RC4 deprecation, there was a similar effect.

 

Some additional details below:

 

SHA-1

SHA-1 is a broken hash algorithm with increasingly significant attacks in recent years (2015, 2017, 2020), so we have been steadily removing its use from HTTPS. In 2017, we removed support for SHA-1 in certificate signatures. In 2018, we announced the deprecation of TLS 1.0 and 1.1, which use SHA-1 throughout, and plan to disable it by default in Chrome 81. Two uses of SHA-1 remain: a number of legacy cipher suites, and the server signature from some TLS 1.2 servers.

 

The relevant cipher suites use HMAC-SHA-1, which is relatively unharmed by known SHA-1 attacks. However, they use CBC, and all CBC cipher suites in TLS are vulnerable to the Lucky 13 attack, so websites should migrate to modern AEAD-based cipher suites, such as TLS_ECDHE_WITH_AES_128_GCM_SHA256. These are both faster and more secure.

 

The server signature is sensitive to these SHA-1 attacks. Note this is not the signature in the certificate, computed by CAs. It is the signature in the TLS handshake itself, computed by the TLS server software. The TLS working group has adopted a document to deprecate this use of SHA-1.

 

In 2016, we removed support for ECDSA SHA-1 server signatures, but RSA SHA-1 remains. Around 1% of connections from Chrome are to servers which select RSA SHA-1, but we expect the true impact of removal is much lower. Our measurements of top sites suggest around 90% of SHA-1-selecting servers support SHA-2 when SHA-1 is removed. They simply have odd hash algorithm preferences. Thus we are adding a fallback to measure the true impact more accurately.

 

Servers which do not support SHA-2 at all will be impacted by an eventual removal. Using SHA-2 here does not require protocol or certificate changes, so this is primarily caused by outdated TLS 1.2 server software.

 

3DES

3DES is an obsolete block cipher used in some TLS cipher suites as a remnant of SSL 3.0, which is no longer supported. Due to its small block size, it is vulnerable to some attacks when used in long-lived connections. It is also much slower than modern AES ciphers.

 

Around 0.03% of connections from Chrome are to servers which select 3DES cipher suites. Our measurements of top sites suggest around 40% of 3DES-supporting servers support AES when 3DES is removed.

 

Although the impact is much higher, we consider removing SHA-1 server signatures to be much higher priority than removing 3DES. 3DES cipher suites do not impact TLS’s protections against downgrade attacks, so, unlike SHA-1, 3DES browser support has little risk of impacting a correctly-configured HTTPS server.


David
Reply all
Reply to author
Forward
0 new messages