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).
I think that the Go project is lucky to have you. Thank you for what you do!
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)?
> 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.
https://news.ycombinator.com/item?id=50164188
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.
CT logs are supposed to be useful. They serve at least two major purposes: visibility and auditing. Assuming that a CA is remotely well behaved, a site owner can trust that, if a certificate has been issued, then it's in the CT log. An auditor can read a complete record of certificates issued by a CA and attempt to determine whether they all follow the rules. And a CA that issues certificates without logging them is quite likely to get caught. Some browsers won't even accept certificates that aren't logged. And anyone who sees a signed certificate that isn't in the log holds evidence that the CA is misbehaving.
Once the private key has been leaked, this is basically all pointless.
Can a site owner trust that a certificate in their name has been logged? Of course not! An attacker could be signing it on the fly.
Can an auditor read the complete record? The complete record is kind of meaningless if the private key is leaked. But the auditor already knows that the private key is leaked!
Will the CA get caught if they issue a cert that isn't in the log? Yes! In fact, all newly signed certs won't be in the log.
Will browsers that check for log inclusion be protected? Yes, because newly signed certs won't be in the log.
Will anyone who sees a signed cert that isn't in the log hold evidence of misbehavior? Yes!
One might argue that the actual change to the CT system that should be made is a way for a CT operator to insert a statement into the append-only log that they believe a signing key to be compromised and that they will therefore no longer accept certificates signed by that key.
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.