On Thu, Aug 26, 2021 at 12:48 AM Jon Ribbens via Python-list <python-list@python.org> wrote: > > On 2021-08-25, Chris Angelico <ros...@gmail.com> wrote: > > On Thu, Aug 26, 2021 at 12:16 AM Jon Ribbens via Python-list > ><python-list@python.org> wrote: > >> There are so many trusted CAs these days that the chances of them all > >> being secure approaches zero - they are not all equal yet they are all > >> equally trusted. Which is why a change of CA on a site you have visited > >> before is potentially suspicious. > > > > Do any popular web browsers notify you if that happens? I've certainly > > never noticed it with any that I use (and I've transitioned several > > sites from one CA to another). > > There was, if the site was using "HTTP Public Key Pinning". But > that appears to have now been removed in favour of "Certificate > Transparency", which to me seems to be a system very much based > on the "problem: horse gone; solution: shut stable door" principle. > > Another attempt at combatting this problem is DNS CAA records, > which are a way of politely asking all CAs in the world except the > ones you choose "please don't issue a certificate for my domain". > By definition someone who had hacked a CA would pay no attention > to that request, of course.
True, but that would still prevent legit CAs from unwittingly contributing to an attack. But it still wouldn't help if someone can do any sort of large-scale DNS attack, which is kinda essential for most of this to matter anyway (it doesn't matter if an attacker has a fake cert if all traffic goes to the legit site anyway). > > I've come to the conclusion that most security threats don't bother > > most people, and that security *warnings* bother nearly everyone, so > > real authentication of servers doesn't really matter all that much. > > *Encryption* does still have value, but you'd get that with a > > self-signed cert too. > > Encryption without knowing who you're encrypting *to* is worthless, > it's pretty much functionally equivalent to not encrypting. Somewhat. It does prevent various forms of MitM attack. It's all about adding extra difficulties on an attacker, so I wouldn't say "worthless", just because it isn't 100% reliable. Earlier I posited a hypothetical approach wherein the server would sign a new cert using the old cert, and would then be able to present that upon request. Are there any massive glaring problems with that? (Actually, I'm pretty sure there will be. Lemme reword. What massive glaring problems can you see with that?) It would require servers to retain a chain of certificates, and to be able to provide that upon request. It wouldn't even need a change to HTTP per se - could be something like "https://your.host.example/cert_proof.txt"; the same way that robots.txt is done. In theory, that would allow a client to, at the cost of retaining the one last-seen cert for each site, have confidence that the site is the same one that was previously seen. But, maybe we're just coming back to "it doesn't matter and nobody really cares". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
