Comment by agwa
3 days ago
https://gist.github.com/AGWA/5a78186e0f4a7d537b8891a7b46f945... is the list of certificates in Certificate Transparency issued by the blocked CAs as of this time. They appear to be non-malicious test certificates, and the DNS name in the first certificate indicates who likely discovered the issue.
What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)
I did not discover the issue. I just wished to have a rapid and definitive way to test the patch(es).
Am I off base, or should I be surprised that you were able to get the mentioned cert issued in the first place this recently (yesterday)? It seems unexpected that certificates are being actively issued and logged coming from a to-be-forcibly-distrusted part of the hierarchy.
The bugzilla issues mentioned elsewhere suggest at least a mostly orderly removal of trust with issuance stopped several months ago. Your new cert was issued by “CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL”, which presumably chains to the G3 root, and the bugzilla issue seems to say that G3 was going to be dropped from the root lists some time ago but that maybe it would be cross-signed by something still trusted. So I assume that something else is going on.
Was that cert issued via normal means (e.g. ACME)?
I think that the Go project is lucky to have you. Thank you for what you do!
> the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild.
This is indeed huge. Allegedly forged certs aren't spam and do need to be logged. Refusal to log them is a dereliction of duty and will righly undermine trust in the system.
The whole premise of CT logs is that issuance of a cert is an action taken by the CA or at least by the HSM holding the private key. If the entire private key leaks, which appears to be what happened here, then the existence of a certificate containing a valid signature means nothing at all. The CT log might as well record that every possible string of bytes has been signed.
"Certificate Transparency logs are "append-only" and publicly-auditable ledgers of certificates being created, updated, and expired." https://certificate.transparency.dev/logs/
Secretly excluding some issued with a key leak that "appears to be what happened" is not transparency.
CT aren't supposed to be gatekeepers.
If the problem is spam then the solution should be antispam - regardless of allegations of leak.
2 replies →
https://news.ycombinator.com/item?id=50164188
What is the CT log for then, if not to log that?
CT is for logging certificates from trusted CAs. Logging certificates from untrusted CAs is out of scope, and can be harmful as untrusted certificates could be used to spam the log until it's unavailable.
Of course, the notion of "trusted" is complicated. These CAs are no longer trusted by up-to-date clients, but out-of-date clients may continue to trust them. The needs of up-to-date clients take priority over the needs of out-of-date clients.
Alice User goes to Bob's Website on the wifi at Eve's Coffeeshop. Can Eve read or inject sensitive information into Alice's browsing session?
Normally Eve's attempts fail because Alice requires a message to be signed with the private key matching the public key in a certificate for bob.example.com signed by a legitimate CA.
Unfortunately Bob bought his CA from Mal's Domains, and Mal is working with Eve for some reason (for example, Mal has been bribed, hacked, intimidated, legally pressured, etc.)
So in addition to Bob's regular on-the-books cert, Mal issues a second off-the-books cert for bob.example.com and gives it to Eve.
With CT, Alice's browser doesn't just require the cert's pubkey, it requires the server to provide a Merkle proof it was included in a CT log.
The CT log puts Eve and Mal on the horns of a dilemma: If they keep their new cert out of the CT logs, Alice's browser won't accept it. If they put it in the CT logs, Bob can read the log himself (it's public) and Bob can say "Hold it! I didn't order this!"
Bob will switch away from Mal as a TLS provider and complain "Hey everybody, Mal issued this cert I didn't order, customers should stop using him and the people who create CA lists for browsers and OS's should closely investigate whether Mal's CA activities are legitimate." Mal can't deny issuing the questionable certificate, the evidence is in public append-only CT logs for everyone to see.
Did the log operators offer an explanation? You say "likely indicates" and I agree, but I guess I'd expect some noise on m.d.s.policy or somewhere similar, maybe a CT-related site I don't look at.
They did not, but log policy permits logs to reject revoked certificates, so no explanation was required.
Thank goodness for CT.