Remix clone Hacker News

Can someone point me to specific exploits that this key rotation schedule would have stopped?

It seems to me like compromised keys are rare. It also seems like 47 days is low enough to be inconvenient, but not low enough to prevent significant numbers of people from being compromised if there is a compromised key.

▲

Avamander 3 days ago | parent | next [-]

> Can someone point me to specific exploits that this key rotation schedule would have stopped?

It's not only key mismanagement that is being mitigated. You also have to prove more frequently that you have control of the domain or IP in the certificate.

In essence it brings a working method of revocation to WebPKI.

> but not low enough to prevent significant numbers of people from being compromised if there is a compromised key.

Compared to a year?

▲

ori_b 3 days ago | parent [-]

> You also have to prove more frequently that you have control of the domain or IP in the certificate.

That doesn't particularly matter; if someone takes over the domain but doesn't have a leaked key, they can't sign requests for the domain with my cert. It takes a leaked key for this to turn into a vulnerability.

On the other hand, anyone that owns the domain can get a perfectly valid cert any time, no need to exploit anything. And given that nobody actually looks at the details of the cert owner in practice, that means that if you lose the domain, the new owner is, treated as legit. No compromises needed.

The only way to prevent that is to pin the cert, which this short rotation schedule makes harder, or pin the public key and be very careful to not regenerate your keys when you submit a new CSR.

In short: Don't lose your domain.

> Compared to a year?

Typically these kinds of things have an exponential dropoff, so most of the exploited folks would be soon after the compromise. I don't think that shortening to this long a period, rather than (say) 24h would make a material difference.

But, again, I'm also not sure how many people were compromised via anything that this kind of rotation would prevent. It seems like most exploits depend on someone either losing control over the domain (again, don't do that; the current issuance model doesn't handle that), or just being phished via a valid cert on an unrelated domain.

Do you have concrete examples of anyone being exploited via key mismanagement (or not proving often enough that they have control over a domain)?

▲

kbolino 3 days ago | parent | next [-]

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.

▲

Avamander a day ago | parent | prev [-]

> That doesn't particularly matter; if someone takes over the domain but doesn't have a leaked key, they can't sign requests for the domain with my cert. It takes a leaked key for this to turn into a vulnerability.

It does, if someone gets temporary access, issues a certificate and then keeps using it to impersonate something. Now the malicious actor has to do it much more often, significantly increasing chances of detection.

▲

crote 3 days ago | parent | prev [-]

The 47 days are (mostly) irrelevant when it comes to compromised keys. The certificate will be revoked by the CA at most 24 hours after compromise becomes known, so a shorter cert isn't really "more secure" than a longer one.

At least, that's what the rules say. In practice CAs have a really hard time saying no to a multi-week extension because a too-big-to-fail company running "critical infrastructure" isn't capable of rotating their certs.

Short cert duration forces companies to automate cert renewal, and with automation it becomes trivial to rotate certs in an acceptable time frame.