Certificate Revocation: An Animated Clarification

[griffin]

On far too many occasions around here we hear off-handed remarks about revocation of certificates, even in official documentation of processes for solutions that have integrated Let's Encrypt certificates.

I know I share the following reaction with many other frequent contributors of this community:

It's not that certificate revocation is some kind of huge crime. It's that it's wholly unnecessary in so many of the situations in which it's applied. Unfortunately, when it comes to when to apply revocations, well...

Some view certificate revocations like...

when they should be thinking about their private key...

I liken certificate revocations to exorcisms... discussion with incorrect knowledge occurs disproportionately to informed application. It's almost like I'm witnessing...

I'm here today to let you know that this is not the right way of viewing revocations. This is more apt:

Basically if anyone (with your compromised private key) tries to get the issuing CA to vouch for your revoked certificate, they are told...

If you fail to use this knowledge and proceed with abandon, resulting in a website that no longer functions as intended, you should expect to be told that your certificate has been...

So... the moral of this story is to be mindful of your private key and be sure to...

When you're done using a certificate, no need to revoke it. Just handle its private key properly...

[petercooperjr]

Heh. I'm perhaps just slightly too old to properly appreciate the "meme" format, but this was an amusing post.

I'm a bit concerned about telling people to destroy private keys at the end though, just because it's not that unusual for someone to show up with the problem that they did destroy their private key (but shouldn't have). Maybe it's just me, but I tend not to destroy my no-longer-needed private keys but just keep them safely backed up "just in case".

Maybe it's just that I was also hoping that this "story" would better convey the message "revoking a certificate doesn't reduce the amount of work that's needed since now there's less valid certificates, it actually increases the amount of work on the system since now they need to track both the certificate and that it's revoked" but I'm not sure it really does. But now I'm nitpicking something that really isn't intended to be in-depth technical documentation so I should probably just stop typing.

[griffin]

@petercooperjr

Heh. I'm perhaps just slightly too old to properly appreciate the "meme" format, but this was an amusing post.

Thanks. Had to reach people somehow.

@petercooperjr

I'm a bit concerned about telling people to destroy private keys at the end though, just because it's not that unusual for someone to show up with the problem that they did destroy their private key (but shouldn't have).

A reasonable concern though I feel like the context is pretty clear:

@griffin

When you're done using a certificate,

@petercooperjr

Maybe it's just me, but I tend not to destroy my no-longer-needed private keys but just keep them safely backed up "just in case".

In case of what, exactly? Unexpiration of a certificate?

@petercooperjr

Maybe it's just that I was also hoping that this "story" would better convey the message "revoking a certificate doesn't reduce the amount of work that's needed since now there's less valid certificates, it actually increases the amount of work on the system since now they need to track both the certificate and that it's revoked" but I'm not sure it really does.

That's certainly reasonable from the perspective of Let's Encrypt. My focus was on personal behavior and motivations rather than altruism.

@petercooperjr

But now I'm nitpicking something that really isn't intended to be in-depth technical documentation so I should probably just stop typing.

I always encourage peer review. Otherwise my head just becomes an echo chamber.

[petercooperjr]

@griffin

@petercooperjr

Maybe it's just me, but I tend not to destroy my no-longer-needed private keys but just keep them safely backed up "just in case".

In case of what, exactly? Unexpiration of a certificate?

In case it turns out that I did need the server after all. So here's a real-life example of something I did this past week, hopefully not too over-simplified or over-explained but is probably some of each: I was trying out a new mail server configuration (this is all in "the cloud", so it's easy to spin up a new VM that's a copy of the old VM but with the changes I wanted). But I wanted to try connecting to this new system with a mail client and seeing how it worked and making sure that it was working right. So I created a new certificate for this "mailtest" system, and installed it, so I wasn't interrupting my main "mail" system while I was fiddling with things and they were each on their own separate domain names. After a couple days of fiddling and being satisfied with how it would all work, I made the same configuration changes to my "mail" system and deleted the "mailtest" VM. But I still have this "mailtest" certificate. I'm not planning on using it for anything else anytime soon, and don't plan on renewing the certificate when it expires or anything. But it seems silly to me to just destroy the private key, since if it turns out next week that I want to try some other settings or do more tests and spin up another VM for testing things, I can just use it rather than needing to request another one from Let's Encrypt.

Maybe it's a bad habit, but since space is so cheap and private keys can't really be replaced, I tend to be of the "securely backup" mindset rather than "disposable like VMs". (My general approach is that the VM loads its certificate along with the rest of its configuration when it starts, and that the VMs are "cattle, not pets" as the saying goes. But certificates are closer to "pets" if I can stretch the analogy.)

But sure, once it expires there's not much point in keeping it around. I wasn't thinking of "done using a certificate" in those terms, though, I guess.

[griffin]

That makes sense. I was thinking you were archiving old certificates with no consideration of reuse, like one with less than thirty days of life remaining after it has already been renewed. Being conservative with resources that have reasonable purpose is certainly admirable.

[Osiris]

I just leave all the private keys rotting in /etc/letsencrypt/archive/.. I don't re-use them and the certificates have already expired: they're useless, even when they would be leaked. So, yes, I could delete them, but IMO it isn't a security risk to let them lying around.

[griffin]

... other than perhaps serving as a growing source of public-private key pairs. I wonder if someone were to somehow compromise every certbot archive folder in existence that followed the same practice just how quickly RSA encryption would be hobbled.

[felixf]

Private keys of expired certificates are only useful for (AFAIK):

1. Decrypting traffic that you intercepted and stored that used the certificate, assuming no forward secrecy was used. (Hopefully nobody is doing that anymore, but I guess that's wishful thinking...)
2. Forging requests that were supposed to be protected by the certificate, but in reality never happened. Not sure whether this is good for anything though But then, there are sometimes surprising applications which you didn't think of before.

Collecting the definitely won't help breaking RSA though. Maybe it makes exposing weaknesses in random number generations easier than just having access to the public keys, but that won't break RSA.

[griffin]

Would a massive distributed network utilized as a key aggregator not cause harm, especially considering that basically everyone uses the same public exponent? I haven't really studied the implications, but I can't imagine it to be a good thing.

Basically this:

pwnedkeys -- all the keys that should never be used again

on steroids.

[felixf]

If having a massive repo of public/private key pairs would help breaking something, all what you have to do is create a huge amount of them. Everyone can create them. If there would be harm in being able to create many of them, RSA would be inherently unsafe.

[griffin]

I figured finite bits means finite keys. All a matter of processing power and storage space. Otherwise, why bother checking the public keys in certificates against the pwned key list?

[Osiris]

@griffin

other than perhaps serving as a growing source of public-private key pairs.

Those few keypairs (by number) can be easily generated locally. I don't see how collecting keypairs can benefit anyone.

[griffin]

Making your own pwned key list with billions upon billions of key pairs (across everyone using certbot who has saved archived keys in the case of a broad compromise)? Am I misunderstanding something fundamental here?

[felixf]

Do the numbers. How many 2048 bit RSA keys are there (approximately)? How many quarks exist in our universe, and how many femtoseconds (picking a random very small time unit) does the universe already exists? You'll find that there are far more potential 2048 bit RSA keys than there are quarks in the universe, or femtoseconds the universe already existed. So no, even given a lot of time and storage space, collecting keys won't help you.

[rg305]

@felixf

collecting keys won't help you

...Unless...
There is some fundamental difference (that can be found) in the way different systems make private/public key pairs.
[all systems/algorithms were not exactly created equally]

Yes, one system can generate an endless amount of them - but they would all "look" the same.
Seeing all the different "looks" out there could provide one with a different "view" that could potentially be used to exploit particular system type generated pairs (theoretically).

[Osiris]

@griffin

Am I misunderstanding something fundamental here?

If you'd use the certbot archive as source, then it would require a lot of hacking a lot of different servers for a few keys per server. I'm not very afraid of that scenario personally.

[griffin]

Fair point, academically. If the probability of collision is so infinitesimal, why expend the resources to verify that a private key is not "in the wild"?

[petercooperjr]

Any randomly generated key will not match any other, since as you say the probability of collision is so tiny as to basically be 0. So if a key is known to be compromised, then anybody trying to use it didn't generate it correctly like they were supposed to but instead has some terrible misconfiguration. Checking a known-bad-keys list takes some effort, sure, but it's a pretty small effort in the grand scheme of things since humanity has figured out some pretty efficient database structures.

The only thing collecting a ton of private keys might get you is discovering some sort of random number generation flaw specific to one platform, as you say, but even with billions of keys I'm not sure you'd pick up on something as subtle as having a few bits less entropy than it's supposed to. It'd have to be almost as bad as the Debian fiasco to really be able to detect it.

I love what Bruce Schnier said in 1996 (though he's speaking of symmetric 256-bit crypto I think the parallel to 2048-bit RSA is pretty similar):

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)

Given that k = 1.38×10^-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10^-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.

Now, the annual energy output of our sun is about 1.21×10⁴¹ ergs. This is enough to power about 2.7×10⁵⁶ single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2¹⁹². Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.

But that’s just one star, and a measly one at that. A typical supernova releases something like 10⁵¹ ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

Just the numbers involved are so huge it's almost impossible to get one's head wrapped around them. The total number of private keys generated in the world is just irrelevant compared to the number of possible keys.

[griffin]

Is this hinged on nearly ideal entropy though? I feel like humanity's implementation of PRNGs is almost as primitive as its implementation of batteries. I suppose I've just been party to so many questionable PRNG implementations that my faith in them is perhaps significantly below average.

I'm a big fan of Bruce Schnier btw, so thanks for that.

Oh the amount of times I've asked PhD students the difference of inputs between a PRNG and a TRNG...

[petercooperjr]

Well, saying that a random 256-bit key would need 2²⁵⁵ attempts on average to brute-force guess the key is assuming you actually are using 256 random bits, yes. But if your random generator only actually has 250 bits of entropy, or even only 200 bits, and the attacker somehow knows the weaknesses of the random generator, then sure the number of attempts on average to brute-force would be less, but it's still much longer than the lifetime of the universe. That's also part of why we use longer keys than we "need", to help mitigate problems like that and other "breaks" in the algorithm that might be discovered after the key is generated. (I mean, what are the odds of a random number generator bug that means keys only have 15 bits of entropy being undiscovered for years…)