> 2. Even if that was a requirement, they can be faked just like the certificate.
I'm trying to understand how this works. (If they can be faked, then yes, that's fatal for CT, but I don't think the CT proponents acknowledge that, so either someone is very wrong, or the truth is subtler than that.)
The okTurtles blogpost, in the section about the first "inaccurate" claim, says, "The SCT (signed certificate timestamp) is pretty much irrelevant in this type of attack since the MITM either can order CA/log combos to do what they want, or they own and operate one of the 1200+ CAs out there (in a clandestine operation), or they’ve hacked their way into obtaining the CA/log private keys they need to conduct mass-surveillance on any website they want (undetected)."
The words "can order" are linked to a page about national security letters. It's true that CT does not protect you against an arbitrarily misbehaving hegemonic government, but if that's in your threat model, a lot of security analyses fly out the door. In this particular case, though, the malicious actor was not a government, so we can rule that one out. (Much as the Chinese government is an attractive target of blame, in this case, it seems like the misissuance was from a private corporation in Egypt. CNNIC voluntarily reported the issue to Mozilla; though it's unclear if Google alerted them first, clearly there was no governmental intention to MITM here.)
I don't understand what being a CA (either by actually being a CA, or by hacking into one) is supposed to gain you here. CT is designed to protect against CA misbehavior. If the argument is that it doesn't prevent a MITM, it just permits one to be detected, then yes, but that isn't faking an SCT. I'm happy to argue about whether detection vs. prevention is useful, but I just want to be clear that that's a different argument.
So that leaves "they’ve hacked their way into obtaining the CA/log private keys they need to conduct mass-surveillance on any website they want (undetected)". Assuming we're talking about "log" here out of "CA/log", then, first, this significantly raises the bar to an attack. This particular attack was done because a non-CA entity asked a CA to sign an intermediate, and lied to the CA about how it would be used. No hacking was involved. In order to conduct the same attack in a CT world, the entity would also have to set up their own log and get it trusted (who would trust it?), or ask the CA for the CA's private key (which would be a "no, and please stop being our customer"), or hack into the CA.
Second, that presupposes that the CT site's claim that log misbehavior is detectable is untrue in a fairly major way. (This is a reasonable claim to make, I'm just trying to figure out if that's the claim you're making.)
In any case, I don't see an argument that it can be faked just like the certificate. It's significantly more work, and involves suborning a legitimate log. Faking a certificate merely involves abusing an intermediate, which is a product that (unfortunately) gets sold for legitimate use, on trust. That trust cannot be abused to generate an SCT the way it can be abused to generate a signed certificate.
> It doesn't prevent MITM attacks (even Google acknowledges that), so it's not a solution (if preventing attacks is what you want).
It prevents some MITM attacks, by disincentivizing them or making them logistically complicated. It does not prevent all of them. It is not a perfect solution, but it is a partial and pretty good solution. I said in my initial post that it's not my favorite solution, but it's my favorite realistic solution.
In particular, CT would have completely prevented this attack.