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

> But what I think is most important is will this change make security worse?

Yes. It deliberately introduces ambient auth for a channel/transport based auth method, which we have two decades of experience from NTLM/Kerberos to know this causes a host of security issues.

> If you mean the UX isn't great, then absolutely, it is not.

No, I mean at a fundamental technology level. Every aspect of the stack, from issuance, verification, and consumption within an application is layers upon layers of hacks, in which any and every mistake is a critical security issue. I understand that the appeal with mTLS is “it’s not a bearer token”, but please understand that in its current state, it’s not a great tech for achieving that. However, beyond just the “mTLS is designed to be failure prone”, which is more about the design and implementation choices, it was literally designed around a premise that a browser would only make a single HTTP/1.0 connection to the server, request a resource, and disconnect. The idea of browsers making multiple connections to fetch resources was, even in its time, seen to break the security assumptions of mTLS, just as multiple requests (HTTP/1.1) does. In today’s modern world, in which there are many connections, and many requests over these connections, the use of mTLS violates a number of core HTTP design assumptions (e.g. it explicitly violates the assumption that requests are independent and stateless, by adding connection-oriented state across requests, like NTLM/Kerberos do).

The core question here is “Can we make mTLS better”, and it’s important to realize that, in its present form, the flaws are deeper than just a preflight, and the preflight is a symptom of these design issues. The specs I mentioned try to tackle these design issues at their root, and notably, do so by acknowledging that servers must be prepared for requests to come in with the wrong/no credentials. This is why the “use `client-certificate: optional`” is actually a really reasonable and preferable solution: it helps align your auth layer to respect HTTP auth semantics, by having your application layer authenticate requests, rather than having your transport layer perform the authentication and your HTTP layer implicitly rely on it.

-- 
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-787090149