Remix.run Logo
kbolino 3 days ago

I just downloaded one of DigiCert's CRLs and it was half a megabyte. There are probably thousands of revoked certificates in there. If you're not checking CRLs, and a lot of non-browser clients (think programming languages, software libraries, command-line tools, etc.) aren't, then you would trust one of those certificates if it was presented to you. With certificate lifetimes of 47 days instead of a year, 87% of those revoked certificates become unusable regardless of CRL checking.

ori_b 2 days ago | parent [-]

Why is leaving almost 15% of bad certificates in play ok? If it was shortened to 48 hours, then it would make 99.5% of them unusable, and I suspect the real world impact would still be approximately zero.

kbolino 2 days ago | parent [-]

It does not have to be perfect to be better. It's not great that 13% of revoked certificates would still be there (and get trusted by CRL-ignoring clients) but significantly smaller CRL files may get us closer to more widespread CRL checking. The shorter lifetime also reduces the window of time that a revoked certificate can be exploited by that same 87%. While I'd wager most certificates that get revoked are revoked for minor administrative mistakes and so are unlikely to be used in attacks, some revocations are still exploitable, and it's nearly impossible to measure the actual occurrence of such things at Internet scale without concerted effort.

This reminds me a bit of trying to get TLS 1.2 support in browsers before the revelation that the older versions (especially SSL3) were in fact being exploited all the time directly and via downgrading. Since practically nobody complained (out of ignorance) and, at the time, browsers didn't collect metrics and phone home with them (it was a simpler time), there was no evidence of a problem. Until there was massive evidence of a problem because some people bothered to look into and report it. Journalism-driven development shouldn't be the primary way to handle computer security.