Hacker News new | ask | show | jobs
by Roujo 2307 days ago
As I understand it, a CA doesn't have a way of MITMing connections just by virtue of them being the one validating the cert for a certain website. You don't share the private keys of your certs when you generate them[0], you just need for a CA to attest that yes, this certificate's public key is allowed to be used for whatever use you're applying for. ACME doesn't change that, it just allows this verification to be done automatically.

Let's Encrypt doesn't have any more ways of MITMing people using their certs than any other CA - that is, they _could_ do it by generating rogue certs, but that's no different than what Google can already do since they're a CA as well. Plus, certificate transparency logs should make it visible if they ever do so.

0: Barring weird cases I've seen of some companies letting you generate a cert entirely on their website, letting you download the private key once it's done. Which is bad practice for the reason you're talking about right now, since by then you have no assurance that they haven't kept a copy of that private key for later use.

1 comments

Any CA can sign any certificate they want, including ones they generate themselves. If a bad actor got control of, or even could coerce, a CA, and could do the same for DNS, the end users would be hard pressed to know.

It's a very valid attack, although minimal. To say they don't have any way of MITM'ing a connection is wrong even if it's unlikely.

This is what certificate transparency logs are designed to solve.

Chrome and Safari currently validates that a certificate has been published in the publicly available transparency logs as part of considering it valid.

Either Google doesn't publish the certificate in the logs and it's not valid, or they publish it and people are able to see the misissuance.

It's not foolproof, but it makes the attack even less likely.

> To say they don't have any way of MITM'ing a connection is wrong even if it's unlikely.

I totally agree, it's why I qualified it with "just by virtue of them being the one validating the cert for a certain website" and later on adding that they could do so in other ways, like the one you're suggesting. Reading it again makes me realize that it could be understood that way, though, sorry if I wasn't clear enough. Sometimes not being a native English speaker betrays me a little bit. =)

Wouldn't it be equally easy for a CA to MITM a site that got it's real cert from them vs from a different CA?
CAA DNS records aim to make that more difficult, actually, but otherwise AFAIK you're right. =)

https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...

CAA is for telling competent CAs that you don't want to use their service, so as to avoid them being fooled by bad guys who pretend to be you. If you think their methods are dubious or just won't be effective due to how your names are managed, CAA lets you flag that they shouldn't issue for your names at all.

If a CA is incompetent or malevolent it would just ignore CAA records or not check them at all.

It would be a serious bug if a web browser for example went "Hey this site has a cert from Bob's CA but the CAA records for the domain say only Alice's CA is to issue" and rejected the certificate from Bob's CA. The CAA notice is about allowing new issuances right now but maybe last week when I got this certificate from Bob's CA I didn't set that CAA record so that was fine.

It would be valid (maybe not a brilliant idea, but valid) to set CAA to refuse all issuance, changing it only for a few minutes once a week while you do all your certificate changes.

Oh wow, and here I thought having clients check that record was the whole point, as a layer of defense against rogue CAs. Thank you so much, I hadn't realized. =)
> and could do the same for DNS

Google also controls a major public DNS resolver (8.8.8.8) and the most popular browser.

But hey, y'know, they're the good guys or whatever so I'm sure it's fine. (Probably. Right up until the moment when it's not.)