Hacker News Reader

Comment by astrange | Hacker News Reader

You probably can't forge a certificate like that without all the browsers noticing and dropping your CA; there's protections against it.

View on HN

If you're a nation you can just force the CAs that are in your jurisdiction to do whatever you want, or sneak in in various ways so they won't know.

If you use the MITM judiciously, it's very likely that nobody will notice, or that those that notice can be compelled not to say anything.

The browser will notice that it's being given a cert that isn't in the CA transparency log + other hardcoded known certs for top sites and will phone home about it.

What browsers actually do that? And do all CAs support it?

Besides, if you have enough access to the CA, you can just get whatever cert is in the transparency log, though that's almost certainly harder for most nations and CAs.

> you can just get whatever cert is in the transparency log

That would require compromising the certificate requester.

A lot of certificate management services for enterprise customers "helpfully" store the private key files. How many cloud or SaaS vendors automatically handle the private keys as well instead of them being generated and staying securely only on the systems using them? So there are still points of centralization to attack, potentially.

Yes, state actors have been known to steal things like codesigning keys. Microsoft had that happen recently where someone with persistence on a dev machine sniffed them out of crash logs(!).

But it requires a lot more steps.

> What browsers actually do that?

Chrome, Safari, Firefox.

> And do all CAs support it?

Yes, the browsers made them.

> Besides, if you have enough access to the CA, you can just get whatever cert is in the transparency log

No, the CA doesn't have the private key of certs.

That's great! I guess my knowledge is out of date, happy to be wrong about that.

> No, the CA doesn't have the private key of certs.

Woops, yeah good point.

CT means a CA can’t do whatever they want. Your comment is handwavy, do you have any details on the “various ways” you’re talking about?

Physically, or by compromising employees or business owners in whatever legal or illegal means, depending on the country.

Sounds from other comments like my knowledge is out of date though, and browsers have real protections against the obvious ways that used to be possible, which is great news.

I think it’s true that they can do “whatever they want”, but only once, because they’ll lose the right once found. The issue is the time between breach and punishment.

As long as a domain has the CAA record specifying which CAs are allowed to issue certificates for it (I believe CAA checking is now mandatory in the baseline requirements for CAs), coupled with CT, a misissurance by a malicious CA should be immediately detectable.

Of course then the question is how quickly browsers can roll out an update/config to distrust all future certs from said CA.

CT = Certificate Transparency, https://en.m.wikipedia.org/wiki/Certificate_Transparency

https://proton.me/blog/kazakhstan-internet-surveillance (apparently they rolled back pushing this, but this shows some "various ways")

We’re discussing trusted CAs typically bundled with operating systems or browsers here. They have to follow the baseline requirements and at least maintain a semblance of innocence. Directly compromising clients with a typically untrusted root cert is out of scope, and you don’t need an evil CA in that case anyway.

Browsers only enforce that certs were logged to CT logs (because they will fail a TLS connection unless a certificate has valid SCTs attached to them). The actual domain owner will have to monitor the CT logs and call out when they notice a certificate being issued that they didn't request. Without that active monitoring of CT logs by the domain owner, it won't help.

Reply on news.ycombinator.com