LGTM1 to remove support, given that 0.009% of TLS connections divided by ~30 is roughly at our typical threshold. Also given the dominance of subresource TLS connections, it's likely that breakage would hit one of those subresources, making it less likely to cause functional damage (compared to e.g. the navigation request TLS connection).
On Mon, Sep 25, 2023 at 6:03 PM David Adrian <dadr...@google.com> wrote: > 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/CAL5BFfXorTe7SSPt8iZt5ZjVi0Qh8qd%2BPdEGMOzSQj45e0Z1VQ%40mail.gmail.com.
