Ready for Trial: Deprecate TLS SHA-1 server signatures

[David Adrian]

Contact emails

dad...@google.com

Explainer

None

Specification

https://www.rfc-editor.org/rfc/rfc9155.html

Summary

Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was already removed, or in client certificates, which continues to be supported.

This feature can be controlled by chrome://flags/#use-sha1-server-handshakes flag and the https://chromeenterprise.google/policies/#InsecureHashesInTLSHandshakesEnabled enterprise policy.

Blink component

Internals>Network>SSL

Search tags

tls, ssl, sha1

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

At most 0.02% of page loads use the SHA1 fallback. However, we cannot disambiguate between a flaky first connection, and actually requiring SHA1. We expect the actual amount is lower.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/812)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/196)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

Since this takes place before a document is loaded, sites cannot opt-in. We plan on doing a 1% stable experiment and monitoring any increase in page load failures and SSL failures.

Ongoing technical constraints

Debuggability

n/a, this happens pre-devtools

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name

use-sha1-server-handshakes

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=658905

Launch bug

https://launch.corp.google.com/launch/4233200

Estimated milestones

Shipping on desktop	117
DevTrial on desktop	115

Shipping on Android	117
DevTrial on Android	115

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4832850040324096

Links to previous Intent discussions

https://groups.google.com/a/chromium.org/g/blink-dev/c/rfPtQpqNixk/m/WF3a12okCgAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Wed, Jun 7, 2023 at 7:15 PM 'David Adrian' via blink-dev <blin...@chromium.org> wrote:

Contact emails

dad...@google.com

Explainer

None

Specification

https://www.rfc-editor.org/rfc/rfc9155.html

Summary

Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was already removed, or in client certificates, which continues to be supported.

This feature can be controlled by chrome://flags/#use-sha1-server-handshakes flag and the https://chromeenterprise.google/policies/#InsecureHashesInTLSHandshakesEnabled enterprise policy.

Blink component

Internals>Network>SSL

Search tags

tls, ssl, sha1

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

At most 0.02% of page loads use the SHA1 fallback. However, we cannot disambiguate between a flaky first connection, and actually requiring SHA1. We expect the actual amount is lower.

0.02% sounds like a lot. Is there a way to get a tighter estimate of potential breakage?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BEWSvOO%3D4QhGfWnRC6Q03VTqrQjPfypFKzwU7aZXGwSQ%40mail.gmail.com.

[David Benjamin]

On Thu, Jun 8, 2023 at 1:18 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Jun 7, 2023 at 7:15 PM 'David Adrian' via blink-dev <blin...@chromium.org> wrote:

Contact emails

dad...@google.com

Explainer

None

Specification

https://www.rfc-editor.org/rfc/rfc9155.html

Summary

Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was already removed, or in client certificates, which continues to be supported.

This feature can be controlled by chrome://flags/#use-sha1-server-handshakes flag and the https://chromeenterprise.google/policies/#InsecureHashesInTLSHandshakesEnabled enterprise policy.

Blink component

Internals>Network>SSL

Search tags

tls, ssl, sha1

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

At most 0.02% of page loads use the SHA1 fallback. However, we cannot disambiguate between a flaky first connection, and actually requiring SHA1. We expect the actual amount is lower.

0.02% sounds like a lot. Is there a way to get a tighter estimate of potential breakage?

Only by shipping it and trying it, unfortunately. Network protocols work differently from most web platform changes. Keep in mind that TLS negotiation is client-offer, server-select. This means the client offers a list of options and then the server picks one. The server could implement any selection algorithm it wants, from "I prefer SHA-256 over SHA-1" to  "I prefer SHA-1 over SHA-256" to "I will use the client's preference order" to even implausible ones such as "I will pick SHA-384, but only if you offer SHA-1".

Usually, we assume that the server's preferences align with ours, and will only pick the deprecated option if there is no other choice. Thus we just measure the final selected value. This isn't a perfect predictor, but it usually works well enough. Here, however, it does not work. Older Windows servers will preferentially sign with SHA-1, but still support signing with SHA-2. Let's call these SHA-1-preferring servers. SHA-1-preferring servers are fine and will not break. Only those that sign with nothing else, SHA-1-requiring servers.

Simply measuring the SHA-1 selection buckets both SHA-1-preferring and SHA-1-requiring servers together. Accordingly, we put SHA-1 behind a fallback three years ago. (That was also the year we had a chosen-prefix collision for SHA-1, so it is well past time to get it out of here. See RFC 9155, linked in the original email, for further details.) First we try without SHA-1 offered, then we offer SHA-1 and try again.

https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ

This works to throw out many of the SHA-1-preferring data points, but not all of them. As David noted, fallbacks are inherently flaky and imperfect. We cannot distinguish between a flaky connection to a SHA-1-preferring server, vs. a reliable connection to a SHA-1-requiring server. Thus this number is inherently an overestimate.

(Also a quick correction: 0.02% is measuring TLS+TCP connections, not page loads. The distributions are slightly different. For instance, a user that spends a lot of time on a single page will, with HTTP/2, record only a single connection because of connection reuse. With HTTP/3, they won't record a TLS+TCP connection at all. Thus these numbers also undercount modern sites and overcount older ones. This is another place where the net stack, particularly at the TLS layer, works differently from most web platform changes.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXb%2BN3EnqXO6JSQLKyTmEsL_SoCbm-5nk1zGp6LM608Lg%40mail.gmail.com.