> These attacks might be "detectable" after they've happened, but so what? So was this one. Damage will have been done.
Well, in this particular case, there was presumably an intention to conduct the MITM long term. Buying a Palo Alto Networks device, paying for a (fairly expensive!) unconstrained intermediate, and being able to MITM a connection for a few hours is not very useful.
There are certainly attackers who want to MITM a specific site for a specific user for a short period of time, and CT may not solve that. It may be the case that no certificate-based system can solve that, because those attackers will prefer spear-phishing the user into downloading malware to reconfigure their browser. But this particular attack was not such a case.
What went (somewhat) wrong here is that the attacker believed that they could get away with it for quite some time, because the mechanism by which Chrome tattles on illegitimate certificates is proprietary and not well-understood as a part of the system. I suspect that if the attacker knew that this would not work for more than, say, a day, then they would have chosen a different, less-attacky route to solve their actual problem.
(Besides, the Palo Alto device would not have actually sent certs to a log. The attacker would have had to write their own MITM proxy, which is a tricky business. That rules out some but not all actual attacks, and if our metric is what actual attacks are prevented, then that counts for something.)
> All the attacker has to do is send the cert to a log, and all CA-signed certs are accepted, so they would have gotten their SCT without any trouble at all.
I concede that that is true; I implied otherwise because I didn't think hard about that part. Thanks.
> After some time, Google might query the log that it was sent to and discover the SCT and raise the alarm
I don't see why the CA wouldn't immediately query logs for all certificates that chain off of their intermediates, to verify that intermediates are only used in the way that people said they'd be used. (Remember that in this case, the customer lied to the CA and said it would only be used for sites the customer had control over.) I could easily imagine that, in a SCTs-are-mandatory world, it's also mandatory for CAs to run this little shell script if they want to be allowed to sell intermediates. It's just a technical formalization of something that's already in the Baseline Requirements.
> it's even possible that the MITM will prevent any fixes from making their way to the victims.
That's certainly an interesting problem and I haven't seen much discussion of it.
Is it possible to configure the browser to fail closed if it hasn't reached its update server within some period of time? Is this something that CT can/should do? Can we standardize something like Chrome's CRLsets, and make the browsers require they be able to reach CRLsets somehow, either through the vendor or through a CT log?
What's DNSChain's solution here? Can a MITM pretend that the blockchain hasn't moved in a few weeks?