Re: [whatwg/fetch] Clarification on CORS preflight fetches for TLS client certificates (#869)

This is in reply to @sleevi in the other issue (https://github.com/whatwg/fetch/issues/1181: Promp for/send TLS client certificates for CORS preflights):

> The Chrome side is most definitely a bug, and while organizational changes have inhibited us from fixing, we do see it as a bug that can and should be fixed.

I'm proposing to change the spec so that client certificates *would* be sent during a preflight (and then it won't be a bug in Chrome). But what I think is most important is *will this change make security worse?* (because this is the reason why credentials are not sent in preflights in the first place).

I think not because the same client certificate promp is possible to trigger using a non-preflight requiring fetch, or even with an `<img src="https://cert-requiring-other-origin.com/image.png">`

> Prompting for sub-resources is equally an anti-pattern, in that it's confusing to end users to understand what, why, and how. Browsers have been moving away, particularly for subresources, from prompting the end user for credentials.

UX-wise, using client certificates is a burden indeed (the prompt can't be designed, cert install is manual, you won't be prompted again if certificates are optional and you chose not to send one in the beginning, but then want it to be sent one in tho future to the same host, etc. Painful).

The up-side is that it's based on public key crypto and known to be secure, and also, web content is known not to have any access to these (unlike cookies, HTTP authentication headers etc).

> The premise that this information is OK to leak is also flawed, because such information very much should be considered sensitive, both in terms of identifying the user to potential network adversaries, and to the end-server.

What I meant to say was that in public key cryptography certificates are public, so when someone is eavesdropping and saving the certificate then it still won't make it possible for the attacker to authenticate with it.

> The problem stems from the fact that, at the core, client certificates are poorly designed and violate a number of good security practices. At a minimum, using optional is the expectation, but as you note, even then, it can be problematic. Proposals have been made (e.g. Secondary Certificates, CATCH) to move this up to the application layer, which is really where they belong.

> I think there's a core takeaway here: mTLS is, and has always been, a giant hack. Literally, its introduction in SSL2 was merely a "we might want this", not with any fundamental design considerations, and its interactions with HTTP have never been well-considered. Just like stream-oriented authentication (e.g. NTLM, Kerberos) has been explicitly forbidden with HTTP/2, mTLS is, at least within the interaction of a broader HTTP stack, a problematic anti-pattern. If you are going to deploy it, as you note, the solution is that your application layer needs to be ready and aware that the client may decline to send credentials, and handle authentication at the request layer (as with every other HTTP authentication method), not at the transport layer.

I don't agree with the above at all. Client certificates are a way to authenticate the client to the server, very much like how server certificates authenticate the server to the client.

If you mean the UX isn't great, then absolutely, it is not. But the choice to accept this inconvenience should be up to the implementer. Sending client certificates in the preflight *will* make using client certificates slightly better in this regard. :) Are there any downsides?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/869#issuecomment-787053521