What can a compromised TLS Certificate Transparency Log do?
One of the potential concerns in the Certificate Transparency ecosystem is that a CT Log could be compromised. But what can an attacker who's in control of a CT log actually do? That's a question both of how CT logs work in general and of the current uses that people make of them, both clients (ie browsers) and Certificate Authorities. So here's what I can see about that, based partly on the TLS client's view of CT logs. To start with, let's restate an obvious thing: a CT Log cannot by itself create a valid TLS certificate. Any real attack requires not just a compromised CT log (or several), but a Certificate Authority that's either compromised or can be used to mis-issue some certificates for you.
(The other thing to say is that no browser relies on a single CT log, and neither should you. Currently, both Chrome and Safari require validation from at least two CT logs, which means that an attacker needs to compromise two of them in order to have a chance of fooling a browser.)
Even without a compromised CA, an attacker in control of a CT Log can make it not work globally in some way or ways. The log can stop giving Signed Certificate Timestamps (SCTs) to CAs when they ask for them as the CAs issue new TLS certificates, either for all certificates or for some of them. It can not actually add some or all TLS certificates to the log, although it gave out SCTs for them. It can stop answering some or all queries about the log (what RFC 9162 calls Log Client Messages), from some or all parties. If detected, all of these would be taken as a sign of a malfunctioning log and would eventually result in the log being dropped from CAs and browsers.
I believe that not answering some queries globally can be used to (temporarily) hide the specifics of some TLS certificates in the log. As far as I can see from RFC 9162, the only way for an outside party to see that specific TLS certificates are in the log is to ask for them (by index position) with a Receive Entries and STH from Log request. If a compromised log wants to hide the presence of some TLS certificates, it can refuse to answer entry queries for any ranges that include the TLS certificates. These certificates are in the log's Merkle tree and it can provide valid proofs of their inclusion, but you can only discover them if you know some details about them (for example, a TLS server gave them to you). To other people trying to audit the log, it might look like ongoing load problems or some other more innocent excuse.
(I suspect that there are enough heavyweight CT log auditors that this excuse wouldn't pass muster for very many days, but it might last long enough for a very special TLS certificate the attacker got to be of some use.)
The simplest non-global thing for a compromised CT log to do is to give the attacker SCTs for special certificates (which can then be put in those certificates) and then not add the certificates to its public, global log. Depending on how much use a browser makes of CT, a browser may well accept a properly signed TLS certificate with these SCTs in it, because all the browser checks is that the SCTs are properly formed and signed. If this was detected, a compromised CT Log could then try to blame the lack of inclusion on general operational issues. Right now, it appears that this SCT-only compromise would probably fool browsers while hiding those bad TLS certificates from all of the people who watch CT logs.
I believe that a compromised CT Log can generate a special version of its Merkle tree that includes extra certificates any time it wants to. This special tree could then be used to create a Signed Tree Head (STH), proofs of inclusion for those certificates in the tree, and a proof that this special tree is an update of a previous legitimate, globally visible tree. However, the careful examination of the STH information might reveal more and more oddities as the tree is generated further and further away from the times in the STHs for the TLS certificates. This special tree's STH will also not be related to the next legitimate, globally visible STH; it will be a one time, frozen fork of the CT log's log.
With more work, a compromised CT log could fork its log into two versions, a private one with extra TLS certificates that were added at the time they were nominally generated and a public version without them. Since this is a fork, the public and private Signed Tree Heads aren't compatible with each other (there's no path from one to the other), so the CT log would have to make sure that any given client only saw either the public version or the private version. How difficult this is depends on how identifiable the client is to the CT log, how it queries the log, and whether or not the client talks to TLS servers that include STHs from the log in their TLS handshake or stapled OCSP response.
Finally, a compromised CT log could return special replies (possibly corrupt ones) to log queries to some clients in an attempt to exploit bugs in the clients. Right now I believe this wouldn't affect browsers, which work only with SCTs and which don't directly get them from the CT logs. It might affect CAs, who directly request SCTs from CT logs and who may audit the logs to make sure that the CA's certificates are present as they're supposed to be, although you would hope that the CA's code would be hardened and well confined, and it could definitely affect anyone who audits CT logs. I suspect that current CT log auditing programs aren't particularly hardened, except through basic implementation language safety (one log monitoring program I know of is written in Go, for example).
(This entry was sparked by Emily M. Stark's Certificate Transparency is really not a replacement for key pinning which got me to start thinking about the cluster of issues around CT logs and CT log compromise.)