5 ms·
In my response from three hours ago about threat model I said “service authentication helps control the blast radius if someone gets inside your perimeter”. I’v
by mmalone 6y ago
In my response from three hours ago about threat model I said “service authentication helps control the blast radius if someone gets inside your perimeter”. I’ve been saying that I think we mostly agree for a while.
If you have a perimeter with well-defined entry points (e.g., a bastion for HTTPS and SSH) then you can lock people out at those entry points. Mutual TLS is defense-in-depth, and how you implement least authority for services inside the perimeter.
I know that CRL is literally active revocation. If you want active certificate revocation you can literally do active certificate revocation. Whether you need it depends on your threat model. And it’s not actually that hard in many scenarios. It is harder than not doing active revocation, and if you find yourself needing it to satisfy your threat model you probably should consider other alternatives for client authentication.
I’m not telling people they should use lots of mTLS but not worry about revocation. Any content I have written that discusses short-lived certificates is very careful to point out the fact that a compromised certificate will be considered valid until it is revoked. Most people who are using our open source toolchain are actually using it for internal server auth TLS, for narrow use cases like issuing certificates for database authentication or VPNs, or for mTLS to satisfy the sort of threat model I’ve described here.
We haven’t implemented anything around active revocation yet. But it is planned, because it is necessary in many scenarios.
If you’re worried about keeping a simple web service running 24 hours a day then you shouldn’t use our stuff. If you’re far enough along to need our stuff, you’ve figured out how to keep a web service running... you have to keep your own web services running 24 hours a day otherwise your microservice system is already going to have availability issues.
- tptacek 6y agoCan you describe a threat model that any medium-sized application --- low tens of microservices, mid-single-digits instances of most of them --- would ever not need revocation? Help me understand where your proposed 24-hour "passive revocation" actually works.
- mmalone 6y agoIf you have a group of services running inside a perimeter with secure entrypoint(s), issuing client certificates allows you to coarsely segment service-to-service interactions within that perimeter to contain blast radius from a malicious insider or service compromise. You don’t need revocation because the credential is useless outside of the perimeter. If you find a malicious insider or a compromised service, you fix the service or lock the insider out of the perimeter. You’re glad that you had client certificates in place as it reduced the scope of the compromise. It would be nice if you could actively revoke any compromised credentials, but it’s not critical because you’ve locked out the offending user and/or fixed the compromised service.
- tptacek 6y agoThis is such a weird position to take: it's so important to keep certificates fresh that you encourage people to set up an infrastructure to run internal ACME and expire certificates in just a matter of hours, but so unimportant to protect certificates, because they're "worthless outside the perimeter", that it's fine to just wait out a compromised key. I think we're probably at an impasse.
- mmalone 6y agoThere are many use cases for internal PKI. This is just one of of them. You’re nitpicking a default. Credential rotation is good security hygiene. To suggest otherwise is malpractice. Our toolchain makes certificate rotation trivially easy. Why not rotate frequently? Hopefully the threat model stuff made sense. It still feels like you actively want to disagree with me, and I’m still not sure why. But I agree that this is starting to feel unproductive. I do appreciate the discussion. I understand your position on client certs better now. Your concerns are valid. Maybe one day we can discuss over beers or something. It feels like that would be the right atmosphere.
- tptacek 6y agoNo, arbitrarily frequent credential rotation is not universally good hygiene, and suggesting otherwise is not malpractice. Why not rotate frequently? Because doing so requires a high-availability CA, and reduces the reliability of the whole system, for marginal or no security benefit.