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.
-
-
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*
Show this thread -
Come on people - we *give* you strongly signed requests, and SPIFFE and ISTIO still do this garbage? Drives me nuts.
Show this thread -
Even BASIC AUTH is better! Even kerberos is better! That's saying something.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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!!
Show this thread -
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.Show this thread -
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!
Show this thread -
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.
Show this thread -
-
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 ...
Show this thread -
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 ...
Show this thread -
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 ...
Show this thread -
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!
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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!
Show this thread -
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.
Show this thread -
Enter an MTLS infrastructure and you have to cross your fingers that they are even logging the user's names. NIGHTMARE to debug.
Show this thread -
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!!
Show this thread -
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!!
Show this thread -
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.
Show this thread -
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!
Show this thread -
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.
Show this thread -
Anyway, that's the rant out of my system! AMA about MTLS if you want, and dear
@Unrollme - please unroll this thread.Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.