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

alexiade left a comment (whatwg/fetch#869)

First, a bit about me. I am an infrastructure/software architect who has been operating in financial-institution infrastructure and fintech for the past decade, and mTLS used as persistent transport security is standard practice there.

Second, a correction. The client's private key isn't held open for the life of the connection. It is used exactly once, in the handshake, to sign the CertificateVerify (RFC 8446 §4.4.3) — a single proof of possession over the transcript. After that, the connection is protected by symmetric session keys derived from the ephemeral (EC)DHE exchange, not by the certificate key, which plays no further role.

And now the rest of it. The core of it being that TLS is a secure protocol on top of TCP/IP, and the web is just one of its many uses.

If you want transport-level security you have three options: VPN, firewalling/origin IP locking, and mTLS. VPNs — pretty much all of them — are based on mutual public-key authentication, the same thing one layer down; but they are made for whole networks and are a hassle to set up. Firewalling/origin IP locking is unusable if your clients have infinite origins, and it's even worse when cloud proxies are used.

What's left for transport-securing single services is mTLS. And this is why it exists. The example with redirect to unilateral TLS is simply not using it as transport-level security, just as service authentication, and that's a totally different use. If you do not need transport-level security and use it as simple authentication, that's fine — but that is not its default use.

Note that this particular shortcut opens the connection to MitM attacks in a very specific way. Hijacked server trust lets you inject a terminating proxy. Most corporate networks do exactly that: they install their own CA for their users and terminate the TLS at a corporate proxy, allowing privacy violations. In those cases, by signing the employment contract, you agreed to them. But any leaked root CA key in the wild would open ALL of unilateral TLS as web uses it to this, by anybody who can configure a proxy for you. mTLS cuts that sort of shenanigan out straight, no ifs or buts. The proxy cannot authenticate the session to the server for the client — it does not have its key. And this is exactly why high-security applications use mTLS.

It's a transport-security mechanism, the same as VPNs and firewall blocks, and browsers should not be interfering with what it does.

So "ongoing transport-layer authentication" isn't an unusual claim — it is the default of modern infrastructure, and it is standardized:

- Service meshes (Istio, Linkerd, Consul Connect) mTLS every service-to-service connection by default; SPIFFE/SPIRE makes the X.509 certificate the workload's identity.
- gRPC ships mTLS as a first-class channel credential for ongoing RPC traffic.
- RFC 8705 (IETF Standards Track) defines mTLS as an ongoing OAuth client-authentication method with certificate-bound tokens; the Financial-grade API profile (Open Banking) mandates it.
- IoT fleets and message brokers (Kafka, MQTT, RabbitMQ, NATS, AWS IoT) authenticate every device/client connection by client certificate.

In every one of those, the certificate authenticates the connection and stays authenticated — no login page, no cookie. That is what mTLS is for, and that is how the rest of the TLS ecosystem already uses it.

Continuous connections are the true face of mTLS.

And in web world, mTLS has a place too as transport security not just as an auth provider. My usecase is one of many. There is a reason why Chrome ignores this particular standard and Firefox has an about:config option to make it ignore it too. This ticket is 7 years old. Nothin has changed besides FF gaining that option. The real world is pretty clear about which way this should be.

I put a lot of effort into this... I understand that people can't be specialists in everything, so this kind of misunderstandings arise... I hope this helps clearing it.

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

Message ID: <whatwg/fetch/issues/869/4692921041@github.com>