GitHub Engineering: When mTLS Is Done Wrong | Hacker News Reader

GitHub Engineering: When mTLS Is Done Wrong

github.blog

84 pointssgammon20 comments

Basically, the good of mTLS is that it's an obvious convenient extension of what is already being done (the TLS handshake). The bad of mTLS is that TLS and X.509 are very non-straightforward and touching them is halfway into "rolling your own crypto".

Not only that, but it seems popular implementations don't necessarily get it right either so using "official crypto libraries" isn't a magic bullet.

It makes me wary of things named mSomething such was mDNSResponder.

mTLS has warts when used cross-origin. Fetch spec says that pre-flight requests mustn't include client certificates[1], so as a consequence servers behind mTLS authenticated proxy won't get a chance to reply to those pre-flight. Yet for non-preflighted requests it's fine to include client certificates..

[1] https://fetch.spec.whatwg.org/#cors-protocol-and-credentials

> servers behind mTLS authenticated proxy

Shouldn't it be possible to configure the proxy to accept any OPTIONS request (i.e. require&validate the client cert after the request headers are passed)?

Honestly that seems reasonable to me. Makes much more sense than the alternative imo.

The issue is that if you do have the client certificate, then (as sibling suggests) now you need to configure your proxy to decide on how to reply to pre-flight requests. Doable but application logic has now leaked into proxy configuration. Another workaround is to use a non-preflighted request, i.e POST with multipart for sending larger amounts of data. Yuck!

Why can't I talk application/json to my cross-origin mTLS service as a normal person? :)

But if you are using mTLS for authentication, you probably don't want random websites to connect with the certificate.

You'll only be able to send client certificates which match the server's CA cert, and if any are found the browser will also prompt you to whether to send it (there'll also be a dropdown when there are more than one).

(Shameless plug.) I had some thoughts in this area.

https://github.com/billpg/CrossRequestTokenExchange

One big issue I see is that you will need to keep the connection open. Malicious client could make the Initiator endpoint to hold the connection open (or to be more exact, they could simply drop the connection after acking the HTTP request), essentially causing 2 long-lived open connections for Issuer (for whatever the timeout is on server).

Thank you just for reading it! I've opened an issue on the project at https://github.com/billpg/CrossRequestTokenExchange/issues/6

If I may rewrite your scenario to check I understand it...

An attacker sets themselves up as an Initiator and registers https://evil.example/TimeOut/ as their URL to receive the TokenIssue POST requests. The attacker then makes a TokenCall request to which the Issuer responds by making the TokenIssue POST request to the malicious "time out" endpoint. As this never responds, that initial connection is kept open.

Yes, though as the "time out" endpoint does not respond, both the initial connection and the connection to "time out" endpoint are kept open.

Thank you, I think that's worth addressing in the questions section and I might have an idea on resolving the issue.

In case you're still reading this, I've updated this document to version 2, answering your comment directly and adding an alternative immediate response instead of keeping the connection open.

As this is still a public draft and not an established standard, I hope discussion will bring a consensus that one way of responding is better and a future draft will only specify that way.

This seems quite similar to the XMPP's dialback: https://xmpp.org/extensions/xep-0220.html

Yeah, the old protocol we're phasing out in favour of mutual TLS auth :)

I should attempt to gather some stats from the XMPP network, but I suspect that since Let's Encrypt made it easy to obtain certs, dialback is probably rarely used. We disable it entirely in Snikket and have had minimal complaints of interoperability issues with other servers.

Thank you. I'll have a read of that and see if there's any lessons I can learn for it that would apply to my proposal.

Video of the presentation:

https://www.youtube.com/watch?v=QNwQ90hI874

external LDAP's, really? in most cases your LDAP will be an AD domain controller, and in this case set the cert username logic in the AD, but NOT query the AD by yourself.

Reply on news.ycombinator.com