On Thu, Jun 8, 2023 at 1:18 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > On Wed, Jun 7, 2023 at 7:15 PM 'David Adrian' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emailsdadr...@google.com >> >> ExplainerNone >> >> Specificationhttps://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 componentInternals>Network>SSL >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >> >> Search tagstls <https://chromestatus.com/features#tags:tls>, ssl >> <https://chromestatus.com/features#tags:ssl>, sha1 >> <https://chromestatus.com/features#tags:sha1> >> >> TAG reviewNone >> >> TAG review statusNot 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 <https://sha-mbles.github.io/> 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.) *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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?No >> >> Flag nameuse-sha1-server-handshakes >> >> Requires code in //chrome?False >> >> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=658905 >> >> Launch bughttps://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 >> <https://chromestatus.com/>. >> >> -- >> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BEWSvOO%3D4QhGfWnRC6Q03VTqrQjPfypFKzwU7aZXGwSQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXb%2BN3EnqXO6JSQLKyTmEsL_SoCbm-5nk1zGp6LM608Lg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaDgR%3DnTeHLuhWhzNgi0nG%2BkLs1BdA5P4WhcrNi_9FL1KA%40mail.gmail.com.
