Thanks for working on this! Would you be able to put this behind a flag <https://chromium.googlesource.com/chromium/src/+/master/docs/how_to_add_your_feature_flag.md#step-1_adding-a-new>, to reduce any risk this might hit in the wild?
It'd also be good to add use-counters to know how common these digests are, but given that the code is fully contained in net/ this might be a bit tricky. Maybe +Adam Rice <[email protected]> and team would be able to help with adding some metrics there? That's not a blocker for this intent, but would help shed light on overall usage of this feature. On Wed, Jun 28, 2023 at 4:15 PM Deomid "rojer" Ryabkov <[email protected]> wrote: > +ericlaw@microsoft > > Eric, could you perhaps provide updated numbers of digest auth usage? (i'm > referring to your previous comment here: > https://bugs.chromium.org/p/chromium/issues/detail?id=1160478#c6) > > > On Mon, Jun 26, 2023, 18:09 David Benjamin <[email protected]> wrote: > >> Not an expert in our HTTP auth code overall, but I don't see any metrics >> for specifically digest auth vs. other HTTP auth types either. >> >> As an upper bound, I wouldn't expect HTTP auth of any form to be common. >> This whole space is mostly a legacy feature as far as the web is concerned. >> I doubt usage would ever completely fall off, but it's not exactly a >> preferred path, or a space that sees much active work. Making modern hashes >> available for Digest seems reasonable enough, I suppose, but I wouldn't >> want to spend more time on it than that. :-) >> >> But I couldn't find good metrics for the upper bound either. >> Net.HttpResponseCode says how often we see 401 and 407 response codes (very >> rarely), but that's a little misleading. If I recall (not an HTTP auth >> expert), for the simpler auth types (Basic and Digest), cached credentials >> are sufficient to preemptively send a (Proxy-)Authorization header. That >> means we'll only see a 401 or 407 on the first go around, up to some >> interesting rules around which paths an auth entry is scoped to. >> >> In terms of breakage risk, since this protocol is server-offer >> / client-select, the client never sends the list of values it supports. >> That means only servers that actually claim to support the new hashes will >> see any change at all. So the risk is limited to early-adopting servers >> that have adopted the new thing but gotten it wrong. Or if we got it wrong. >> :-) (No particular opinions on my end as to whether that makes it worth >> flag-protecting.) >> >> On Mon, Jun 26, 2023 at 10:46 AM Rick Byers <[email protected]> wrote: >> >>> Hi Deomid, >>> Thanks for the contribution! Do you know if chromium has any metrics on >>> how common digest auth is? I took a quick look and didn't find one myself. >>> +David >>> Benjamin <[email protected]> also. Technically all new APIs (which >>> includes protocols) require a killswitch flag >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> >>> since >>> we've seen even new APIs break websites sometimes (eg. in this case >>> presumably it would be from a misconfigured server). But if we have data >>> showing the usage of digest auth is small / insignificant enough, I'd >>> personally be receptive to an argument that that is unnecessary extra >>> bureaucracy. >>> >>> Also it would be nice to know if WebKit has an opinion on this, could >>> you file a position request >>> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u> >>> please? >>> >>> Thanks, >>> Rick >>> >>> On Wed, Jun 21, 2023 at 3:31 PM Deomid "rojer" Ryabkov <[email protected]> >>> wrote: >>> >>>> Hi Daniel, >>>> >>>> I do not anticipate immediate impact. By and large, this is not >>>> currently used because the most popular browser engine doesn't support it. >>>> So people just use MD5, as in the bad old days. >>>> If we ship this tomorrow, nothing changes: servers still send legacy >>>> MD5 challenges, which we continue to support. >>>> As awareness of SHA-256 support by Chrome/Blink-based browser spreads, >>>> I expect service administrators to gradually start transitioning away from >>>> MD5. >>>> The RFC specifies use of multiple algorithm challenges by sending >>>> multiple WWW-Authenticate headers, so there's a good transition path there >>>> for service admins (send both SHA-256 and MD5 challenges, phase out MD5 >>>> eventually). >>>> I verified that with my current code this works as specified (order of >>>> headers specifies server's preference). >>>> Firefox already supports SHA-256, so there's already a capable browser >>>> in the wild, but since it's a minority there isn't much use yet. >>>> As far as deviating from Firefox in also supporting SHA-512-256 and >>>> userhashing, it's again a no-op initially: these won't be used unless >>>> servers explicitly specify that they can be used (for example, for lighttpd >>>> there's an explicit option to enable username hashing, off by default). >>>> If Firefox catches up and also implements these, then we might start >>>> seeing adoption. >>>> >>>> >>>> On Wed, 21 Jun 2023 at 11:18, Daniel Bratell <[email protected]> >>>> wrote: >>>> >>>>> I am missing the compatibility picture here. How will this affect >>>>> existing web pages, and what happens to browsers that do not support this >>>>> is we add support? >>>>> >>>>> /Daniel >>>>> On 2023-06-20 18:13, Deomid "rojer" Ryabkov wrote: >>>>> >>>>> Contact emails [email protected] >>>>> >>>>> Explainer None >>>>> >>>>> Specification https://datatracker.ietf.org/doc/html/rfc7616 >>>>> >>>>> Summary >>>>> >>>>> https://datatracker.ietf.org/doc/html/rfc7616 specifies SHA-256 and >>>>> SHA-512-256 algorithms for the HTTP digest authentication scheme, in >>>>> addition to the obsolete and insecure MD5. It also specifies way of >>>>> concealing the username, provided that server supports it. Firefox >>>>> supports >>>>> algorithm=SHA-256 since 93, but not SHA-512-256 or username hashing. >>>>> https://chromium-review.googlesource.com/c/chromium/src/+/4611879 is >>>>> the pending CL. >>>>> >>>>> >>>>> Blink component Blink>Network >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>>>> >>>>> TAG review None >>>>> >>>>> TAG review status Not applicable >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> *Gecko*: Shipped/Shipping ( >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=472823) >>>>> >>>>> *WebKit*: No signal >>>>> >>>>> *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? >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> 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 >>>>> >>>>> Requires code in //chrome? False >>>>> >>>>> Tracking bug >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1160478 >>>>> >>>>> Estimated milestones >>>>> Shipping on desktop 116 >>>>> Shipping on Android 116 >>>>> >>>>> 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). >>>>> >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/5139896267702272 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> Deomid "rojer" Ryabkov >>>>> [email protected] >>>>> -- >>>>> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>> >>>> -- >>>> Deomid "rojer" Ryabkov >>>> [email protected] >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwryoCQ8j4sfPFh3Ozs%3DKaMDt0xEHFMo61mQXXzVw0eM%3DQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwryoCQ8j4sfPFh3Ozs%3DKaMDt0xEHFMo61mQXXzVw0eM%3DQ%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXtZ4_KzJBtzJQ%2BjErXQxU4VQ%2BSUhC6hXMh4exk00FUtg%40mail.gmail.com.
