On Sat, Oct 02, 2021 at 08:56:18PM -0700, Michael <keybou...@gmail.com> wrote:
> ugh. Well, doing a search shows a LOT of articles about this very > issue -- this was apparently a known "this is going to affect a lot of > people" deal, and "just update your software, or ... sorry." was the > only answer. > > But, I at least did find out why certs expire. > Seriously though: A cert identifies a domain. If you sell/buy a > domain, you want to be able to invalidate all existing certs for that > domain. > > And as I see that, I'm immediately struck by two things: > 1. SSL, and a cert's job, is to validate the connection, not the > person on the other end. It's to prevent MitM attacks. (Putting the > domain name in -- when multiple names can go to the same server? Why?) Warning: Not an expert! I'm not sure I understand what you're asking here. Certificates don't validate the connection. They do validate the system on the other end. Certificates prevent MITM attacks by validating the server to the client (and sometimes by validating the client to the server as well). It makes sense for the domain to be in the certificate, because that's the "identity" what the client thinks they are connect to. If the domain wasn't there, what's being validated? What would stop a MITM attack from replacing one anonymous certificate with another anonymous certificate? In some systems, it's possible to use certificate or key fingerprints instead of domain names to identify the party at the other end of a TLS connection, but it's usually much less scalable than using domain names. > 2. The DNS is the obvious place to put "Here's our fingerprint" or > something to validate a cert -- that would prevent old owner certs > from working. (So why isn't this done?) That can be done, and it is done on a tiny but ever increasing scale. It's called DNS-based Authentication of Named Entities (DANE). And it's great. You don't need Certificate Authorities at all (if every TLS client were DANE-aware, which they aren't). Every domain owner can authenticate their own certificates. The problem is that it relies on the security provided by DNSSEC. Without DNSSEC, you just can't trust DNS. With DNSSEC, you can trust DNS enough to authenticate all sorts of things. Luckily, DNSSEC has recently become incredibly easy to implement. Google's DNS hosting service supports DNSSEC with a checkbox. The recently released new debian stable has a version of the Bind9 DNS server that is recent enough that turning on DNSSEC can be done with a single line of configuration (or a few) and a single (or annual) manual interaction with your domain registrar. It used to be much more complicated. And that's the reason it isn't done. And the fact that DNSSEC traffic is much larger than normal DNS traffic (but well worth it, and it's less with modern keys than it was when DNSSEC started). But DNSSEC deployment is still a very small percentage of all domains, and until it's much closer to 100%, there's little chance that all web browsers will be DANE-aware. There are attempts to include DANE-awareness inside the TLS protocol itself as an extension which would help. But it all seems a long way off. It's currently mostly used for mail servers to protect server-to-server traffic from MITM downgrade attacks. > And I cannot find any good reason for expiring root certs. They > explicitly have much longer lifespans than anything else, and this > isn't the first time that root certs have gone poof. And it won't be the last. Hopefully, this episode will teach creaters of IoT systems and operating systems that no device should ever be designed to ever stop keeping itself up-to-date (at least as far as root certificates and TLS implementations are concerned). :-) I think root certificates need to expire so as to ensure that people take into account the fact that all keys and certificates might need to be replaced one day, and so provisions must be made to prepare for that inevitability. If root certificates never expired, people would almost certainly design systems with the assumption that they would last forever. But they won't. Nothing ever does. Death comes to us all. It's dangerous to assume that no root certificate will ever be compromised and will never have to be revoked. It's better to assume that it will happen. So everyone has to accept the fact that root certificates will need to disappear at some point, for one reason or another, and it's better to build that expectation into the system as regular events, rather than only building it in as catastrophic events. And there are other reasons why root certificates will need to be replaced such as better algorithms appearing, or quantum cryptanalysis breaking all current public key cryptography, or just the existing algorithms individually being broken. The short answer is that the need for responsible cryptographic key management applies at least as much to root keys as it does to any other keys. > Off the list topic now. Thanks for your help. cheers, raf