Related: Bug 328655

I agree that we shouldn't use client certs for credential-omitted requests. The bugzilla bug isn't really clear though: have you verified that this is happening, Mike?

Regardless, not sure which category in `Internals>Network` this falls into, but my vague impression is that this happens somewhere in the network stack, so... Hi, network folks!

> have you verified that this is happening, Mike?

I haven’t independently tested it but I’ve seen two different reports on StackOverflow that appear to pretty clearly indicate it’s happening:

* https://stackoverflow.com/questions/46783506/why-is-the-tls-client-certificate-not-being-included-in-preflight-request-on-mos
* https://stackoverflow.com/questions/40663641/cors-with-client-https-certificates

I've heard several questions related to this, but so far, no one has provided a repro (and more specifically, have been unable to find confirmation that an enterprise policy to always send client certificates is not set).

The network stack itself doesn't have a notion of CORS - the closest approximation is load flags (do not save/set cookies, do not send HTTP auth data). It just passes the request up the stack. It's probably related to https://cs.chromium.org/chromium/src/net/http/http_network_transaction.cc?rcl=c39432b787ac8c8bb6c38e5e14e5e793653ec427&l=1455 - which skips passing the request up if there's a previous affirmative auth cache entry, and as it (by design) doesn't know about CORS, and 'privacy mode' is just a bookeeping entry. 

> so far, no one has provided a repro (and more specifically, have been unable to find confirmation that an enterprise policy to always send client certificates is not set)

At https://stackoverflow.com/questions/46783506/why-is-the-tls-client-certificate-not-being-included-in-preflight-request-on-mos#comment80531465_46783506 I’ve asked the OP of one of the StackOverflow questions to comment on that

Issue 324871 (Sorry, restricted) was specifically about a feature request to enable TLS client credentials on preflights, because they weren't sent.

I suspect the difference is due to HttpNetworkTransaction's cache of client certs; if you'd previously visited the origin (and affirmatively authenticated), then credentials are included, regardless of the XHR or fetch() flags. The previous bug was about decisively cross-origin requests on the first visit - which would omit the credentials (as the loader layer would reject before prompting, and the 'auto-select' logic happened right before prompting but after loader)

mmenke: One approach to resolve this would be to introduce a LOAD_FLAG similar to what we have for the HTTP auth cache (LOAD_FLAG_DO_NOT_SEND_AUTH_DATA) - or potentially even overload LOAD_FLAG_DO_NOT_SEND_AUTH_DATA to include client certs. The latter seems greater risk, but potentially aligns with 'client certs are auth data', while the former offers less risk, but introducing another load flag. Curious your thoughts.

My preference would be to overload LOAD_FLAG_DO_NOT_SEND_AUTH_DATA, if we can - the fewer knobs, the better.

To elaborte a bit, with multiple knobs, we end up with people using random subsets of them, unsure of what they really want, particularly when it comes to something as obscure as client certs.  They often really want the same thing, but are unsure of how to get it.  I'd prefer we avoid that, if we can.

Looking at consumers using LOAD_DO_NOT_SEND_AUTH_DATA, almost all of them aren't sending cookies, too, so I think it's safe to say they generally don't want any ambient credentials at all.

re Comment #9: I'm not entirely sure that's true. That is, I believe some of these consumers are relying on ambient credentials from enterprise policies for testing, and could elaborate offline more (to avoid restricting this bug as the other bugs). That's my concern on risk.

That said, I'd rather be bold and clean here, and agree with you on the trade-offs. I whipped up https://chromium-review.googlesource.com/#/c/chromium/src/+/723780 as a quick sanity check. It's not ready to land, because a number of tests are needed (HttpNetworkTransaction, URLRequest, InProcBrowserTest, and ideally a WPT test - although I'm not sure WPT even supports this case)

> although I'm not sure WPT even supports this case

I’m not sure it does either, but will investigate and find out

Thanks for looking into this, rsleevi@/mmenke@! FWIW, I agree with both of you that overloading the existing flag seems like the right way to do this, but I'll defer to you on implementation details and edge cases. :)

Here's a question that's unclear from Fetch - or what other implementations do.

Changing it as I propose would mean that the request is aborted (ERR_SSL_CLIENT_CERT_REQUIRED), but it may also be possible to continue by affirmatively sending 'no' certificate (responding with an empty cert and restarting).

Do we know what other browsers do? Do they abort the request if auth is requested, or continue it?

Aborting would align with how HTTP is handled (it's explicitly signaled by a 403), but not how cookies are handled (just quietly omitted)

I'm not so sure it aligns with how HTTP is handled - we display the 403 error page we get from the server, as opposed to a Chrome-generated error page.  I don't believe putting the resulting sockets in privacy mode socket pools is a problem, as long as non-privacy mode sockets to the same origin can still send certs?  That having been said, I don't have strong opinions here.