There are approximately 30x TLS connections relative to pageloads, due to subresources. Once you have a TLS connection open for a main frame, I'm not sure how many page loads happen across it. Probably a lot, but it's still dominated by subresources.
In practice, the 0.02% bound appears to have shaken out to sub 0.01% (0.009%), determined by looking at differences in the "OK" result for Net.SSL_Connection_Error. On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > > > On Wed, Sep 20, 2023 at 12:47 AM David Benjamin <david...@chromium.org> > wrote: > >> On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> On Tue, Sep 19, 2023 at 1:35 AM 'Jeffrey Yasskin' via blink-dev < >>>> blink-dev@chromium.org> wrote: >>>> >>>>> On Mon, Sep 18, 2023 at 4:11 PM David Adrian <dadr...@google.com> >>>>> wrote: >>>>> >>>>>> > This should probably be an "Intent to Deprecate and Remove" rather >>>>>> than an "Intent to Ship". >>>>>> >>>>>> You're absolutely right that it should be, unfortunately that's not >>>>>> the subject Chrome Status generated. I'll file an issue. >>>>>> >>>>> >>>>> Oops, yes, you did everything right here. There's already >>>>> https://github.com/GoogleChrome/chromium-dashboard/issues/2749 about >>>>> changing this subject line, and now >>>>> https://github.com/GoogleChrome/chromium-dashboard/issues/3346 to >>>>> align the Chrome Status UI with the launching-features page. >>>>> >>>>> > The RFC's introduction at >>>>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a >>>>>> pretty good explainer for why we should remove SHA-1 signatures. >>>>>> >>>>>> Agreed. Noting in general, there is a large process mismatch between >>>>>> TLS launches and the Blink launch process, as discussed in >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CmlXjQeNWDI/m/r-AUe0OqAQAJ. >>>>>> That's why this Intent looks a little different. >>>>>> >>>>> >>>> I wouldn't categorize it as a large process mismatch. But that's an >>>> orthogonal discussion. >>>> >>>> >>>>> >>>>>> As for the launch itself, I'll note it's been at 10% on Finch for a >>>>>> couple weeks and everything looks gray, so we should be safe to ramp up >>>>>> to >>>>>> 100%. The only thing of note was a correlation with an unrelated >>>>>> crash in Blink >>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1479083#c2>, >>>>>> since the deprecation rollout was fairly large. It only showed at 10%, >>>>>> not >>>>>> 1%. >>>>>> >>>>> >>> How would we know of breakage in those 10%? Would that look like users >>> filing issues? Something else? >>> >>> >>>>>> On Mon, Sep 18, 2023 at 3:53 PM Jeffrey Yasskin <jyass...@google.com> >>>>>> wrote: >>>>>> >>>>>>> This should probably be an "Intent to Deprecate and Remove" >>>>>>> <https://www.chromium.org/blink/launching-features/#feature-deprecations> >>>>>>> rather than an "Intent to Ship". I'll let an API owner say if there's a >>>>>>> reason to re-send it; probably there isn't. >>>>>>> >>>>>>> On Mon, Sep 18, 2023 at 3:47 PM 'David Adrian' via blink-dev < >>>>>>> blink-dev@chromium.org> wrote: >>>>>>> >>>>>>>> Contact emailsdadr...@google.com >>>>>>>> >>>>>>>> ExplainerNone >>>>>>>> >>>>>>> >>>>>>> The RFC's introduction at >>>>>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a >>>>>>> pretty good explainer for why we should remove SHA-1 signatures. >>>>>>> >>>>>>> >>>>>>>> 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. SHA-1 can be temporarily >>>>>>>> re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled >>>>>>>> enterprise policy. This policy will be removed in Chrome 123. >>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>> >>>> Are we thinking that 0.02% is a loose upper bound? Is that correct? >>>> >>> >> As with anything in TLS, the protocol is client-offer / server-select, >> which means we pick up all the implications of that. We can measure what >> the server selects, but that doesn't actually tell us what will happen if >> we change the ClientHello: >> - Perhaps the server preferentially chooses SHA-1, but will pick SHA-2 if >> not offered. (I.e. SHA-1-preferring instead of SHA-1-requiring) >> - Perhaps the server picks SHA-2 regardless but, for some odd reason, >> breaks when SHA-1 is not offered. This could be a buggy, non-compliant >> fingerprinting script, or some weird behavior. >> >> Usually, these effects are small enough that we just measure the server >> selection and don't worry about it. Here, we could not do that. First, we >> knew from previously sampling sites that some servers (older IIS) fall in >> the first category. These servers would not break, but would seem to break >> if we measure the server selection. We also knew, again from sampling and >> due to the multiple places where this ClientHello field is used, the second >> category also shows up (in many cases, also older IIS). These servers would >> break but would seem not to if we measure the server selection. >> >> Thus, we used a different measurement strategy. We send a SHA-1-less >> ClientHello and then, on error, retry with SHA-1 restored. This does not >> work for security (an attacker can always force us onto the second round), >> but it helps counteract the above effects for a more accurate >> measurement... up to a point. Up to a point because, in exchange for >> clearing those effects, we pick a different effect: transient network >> errors will also trigger the retry. And thus our numbers inherently have >> noise at the scale of transient network errors. >> >> See also >> https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/ly5-WQEBBgAJ, >> where we previously discussed this same client-offer / server-select >> property. >> >> This is a difference from web platform things, where we can simply >> observe in Chrome what APIs the site uses and moves on. >> >> >>> Any way to sample a few sites to validate that assumption? >>>> >>> >> I'm not sure what you mean. Networks occasionally flake, so any kind of >> fallback measurements will capture some flakiness. Sampling sites won't >> tell us anything about that. >> > > For web platform features, where we have both usecounters in the > HTTPArchive and potentially UKM, we can gather potentially breaking > URLs/origins, grab a few dozens random names from the list and deep dive > into them to see if they show breakage or not. > > I'm not sure that we have anything similar for the netstack, where we > could e.g. report the failures in ways that enable us to later follow up > and run a similar manual check. (e.g. by reporting the failing DNS name > and/or IP) > > >> >> >>> Also, are those 0.02% driven by origins? Specific user platforms? >>> Something else? >>> >> >> This is 0.02% of TLS connections (sorry, page loads was a typo). >> > > OK, that seems better, as presumably the denominator is smaller then it > would be for page loads (which is what we typically use). Do you have a > sense of the difference between denominators? (so, how many page loads > typically happen per TLS connection?) > > >> This is another of those differences between networking and web platform >> features. The denominator is unavoidably different because of where in the >> stack this logic applies. Where it is actually an incompatibility with a >> site, it will be based on the origin. This is almost always due to a bug in >> the server software because every TLS 1.2 implementations supports SHA-2. >> (E.g. very very old OpenSSLs, with several known, unrelated security >> vulnerabilities have a bug where, with some server software, mess this up.) >> >> Where it is a transient network error above it is, well, a transient >> network error and presumably driven by network conditions. >> >> >>> >>>>>>>> *Gecko*: Positive ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/812) >>>>>>>> >>>>>>>> *WebKit*: Positive ( >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> 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 name on chrome://flagsuse-sha1-server-handshakes >>>>>>>> >>>>>>>> Finch feature nameDisableSHA1ServerSignature >>>>>>>> >>>>>>>> Requires code in //chrome?False >>>>>>>> >>>>>>>> Tracking bug >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=658905 >>>>>>>> >>>>>>>> Launch bughttps://launch.corp.google.com/launch/4233200 >>>>>>>> >>>>>>>> Estimated milestones >>>>>>>> Shipping on desktop 117 >>>>>>>> OriginTrial desktop last 116 >>>>>>>> OriginTrial desktop first 115 >>>>>>>> DevTrial on desktop 115 >>>>>>>> Shipping on Android 117 >>>>>>>> OriginTrial Android last 116 >>>>>>>> OriginTrial Android first 115 >>>>>>>> DevTrial on Android 115 >>>>>>>> OriginTrial webView last 116 >>>>>>>> OriginTrial webView first 115 >>>>>>>> >>>>>>>> Anticipated spec changes >>>>>>>> >>>>>>>> Open questions about a feature may be a source of future web compat >>>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>>> issues in the project for the feature specification) whose resolution >>>>>>>> may >>>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>>> structure of >>>>>>>> the API in a non-backward-compatible way). >>>>>>>> None >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> https://chromestatus.com/feature/4832850040324096 >>>>>>>> >>>>>>>> Links to previous Intent discussionsIntent to Experiment: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42JZz%3De_TRVwumqgTj-A7543BR7JLBUR_GzVN_oOWhKVvg%40mail.gmail.com >>>>>>>> >>>>>>>> >>>>>>>> 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/CAGkh42LiSGgfN1trVXfrmCW0Upk9r9GK4XYZQm5Y8RSzphn_DA%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42LiSGgfN1trVXfrmCW0Upk9r9GK4XYZQm5Y8RSzphn_DA%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/CANh-dXnM7SzAOh2y6hcuezDpo-yCW%3DtNg0%3D1ErEMCFN%3DSSpsQQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnM7SzAOh2y6hcuezDpo-yCW%3DtNg0%3D1ErEMCFN%3DSSpsQQ%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/CAL5BFfVPG6np80msDXGDyzqOMA6E-7mtqFQpDSw8w5m3X%3DEKOg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVPG6np80msDXGDyzqOMA6E-7mtqFQpDSw8w5m3X%3DEKOg%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/CAGkh42Ktq%2BY7cDPu4iFo1v7Y5dn8XCPk9UJB%2BJxe8-9Wo-QO8w%40mail.gmail.com.
