Should/can this also be applied to WebRTC's DTLS connections? (we don't have numbers but that can be fixed)
Am Mo., 25. Sept. 2023 um 19:13 Uhr schrieb Yoav Weiss < yoavwe...@chromium.org>: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXorTe7SSPt8iZt5ZjVi0Qh8qd%2BPdEGMOzSQj45e0Z1VQ%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/CADxkKiJNbDw%2BDTzgSCKHWFDyoC4mQsmS9q_HRHiD24C3CswpPw%40mail.gmail.com.
