Ok. tweet thread time! Too long ago I promised to write a screed explaining how much I hated mutual-auth TLS and why. I got distracted, and I wasn't happy with the writing, so here it is in tweet thread form instead! But basically: Client certs and Mutual-Auth TLS is TERRIBAD.
When I say TERRIBAD, I mean that unless you've got the resources of a big security dept and folks who comb threat models for a living, using clients certs and mutual auth probably materially lessens your security. That's NUTS! Let me recount the many ways.
O.k some background. So Mutual Auth TLS, also called Client Auth TLS, or Client Certs, or MTLS, are all names for that crazy setup where you generate or give certificates to your clients and have them connect into your service. Seen in Intranets and MySQL conf since 2000.
Let's start with the big elephant in the room: MTLS is one big GIGANTIC layering violation. Authenticating users at the channel/session/network layer ... for actions that happen at a higher layer, like HTTP requests, or SQL commands. How is that bad?
Well it means that trivial security issues like SQL injection and request smuggling in HTTP headers ARE STILL THINGS IN TWO THOUSAND AND EIGHTEEN. Forget to escape a parameter and boom .. the attacker than put requests right there in your "authenticated" stream. *HEAD DESK*
Come on people - we *give* you strongly signed requests, and SPIFFE and ISTIO still do this garbage? Drives me nuts.
Even BASIC AUTH is better! Even kerberos is better! That's saying something.
O.k. so just authenticating a channel at all is BAD, but TLS is even MUCH worse at this than you think. Starting with ... it's common to FAIL OPEN. Default TLS server configurations "just work" and let anyone in! it's not even a mis-configuration really. I've seen this TOO OFTEN.
But ok., so you check that's locked down. But did you know that TLS connections can be re-negotiated, and re-AUTHENTICATED? It's nuts!! But yes, TLS supports this. The client can at any time decide to change the auth context.
Did you know there might be a DIFFERENT CLIENT CERT for each byte of the request? Hell, there can be an infinite number even between the byte! Again, layering violation! Which cert applies? Who knows!!
Btw @marshray basically told us all this 9 years ago!! And implementations still don't handle it right, because it's incomprehensible. You can turn off renegotiations wholesale, but then you might over-use a key! *sigh* no-win. TLS1.3 does fix this though.
Directly related to all of this is that it takes an enormous amount of code to do mTLS. An ordinary TLS server can more or less ignore X509 and ASN.1 - it doesn't need to parse or handle them. Turn on MTLS and all of a sudden it does!
Take it from me that you don't want a trusted service responsible for your AAA stack also parsing X.509 and ASN.1. Nuts nuts nuts.
We're still only GETTING WARMED UP btw!
Let's ask the most important question in the design of any AAA system: how do we handle the inevitable compromise of the credentials? So what are the common answers ...
I have never ever ever, not once, seen a working revoking system. In THEORY there's this idea that the bad cert can be listed in a CRL, and the servers all refresh it and we're good. I've seen half solutions at best. Common problem ...
What if you need to replace *ALL* your credentials? "This would never happen!" ... except Heartbleed, and the Debian RNG bug, and those Eastern European smart cards, and, and ...
and how do you update the clients quickly? Do you have a way to prompt people or let them know? PASSWORDS are so much better at all of this!
Can you grow your CRL infinitely for it all? NO? So you need a story for root key revocation anyway?? Oh man. Who has this stuff down? No-one is who.
So instead people use "short certs". O.k. first let me point out that the security of this solution depends on how secure your server clocks are. If I can spoof NTP ... it was all .. dumb ... anyway.
Next, let me ask, is there ANY good value for length of time here? Make it too short and you're going to have a lot of outages due to failure to renew certs quickly enough, Too long and it's not secure.
Google's ALTS dodged a lot of this by having epochs that end up being a mix of time and CRL-like strategies. Smart move and dampens the tyre-fire somewhat. Never seen in the wild though!
Now we get to my LEAST favorite part ... there are basically NO standards for logging credentials from certs, or for implementing authz. So admins just make up their own.
Enter an MTLS infrastructure and you have to cross your fingers that they are even logging the user's names. NIGHTMARE to debug.
And for authz the admins get "creative". Because certs basically encode strings, people start using them as arbitrary bearer tokens. Let's put group permissions in the cert itself, encoded in strings ... and then do access control with ... REGEXes!!
ACTUAL SECURITY ISSUE I SAW IN THE WILD: The "administrative-assistants" has root-level access to everything for years, because their group name started with "admin" and the regex letting them in lacked a $ terminator!!
Disclaimer: they were using Apache 2.0, and I wrote that regex supporting madness, and so it is my fault and I will pay for my sins.
Anyway, back to MTLS, it is a hodgepodge of awfulness. Massive code base to implement, terrible standards in the middle, and just obscure untested garbage left and right. RUN AWAY!
Yet it gets a reputation for being a best practice, maybe because it's hard, or because it has a halo from the false talisman of cryptography. *shudder* BAD, BAD, TERRIBAD.
Anyway, that's the rant out of my system! AMA about MTLS if you want, and dear @Unrollme - please unroll this thread.
