Hacker News Reader

Comment by oefrha | Hacker News Reader

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?

View on HN

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.

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.

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.

Reply on news.ycombinator.com