AFAIK that's not a required feature of the DV process, and even if it were it wouldn't help if the MITM was happening between the website and the wider internet.

That said, I don't think there's a way to stop a nation state from seizing control of a domain they control the TLD name servers for without something like Namecoin where the whole DNS system is redesigned to be self-sovereign.

Multi-perspective is or will be (I didn't pay attention to the timeline) required by the Baseline Requirements which are effectively the rules for how Web PKI certs work.

The system is tamper evident not tamper proof. A nation state adversary can indeed impersonate my web site and obtain a new certificate, but the Web Browser doesn't trust that certificate without seeing Proof it was in the CT logs. So, now the nation state adversary need Proof it was Logged.

Whoever issued them the proof has 24 hours to include that dodgy certificate in their public logs for everyone to see. If they lie and don't actually log it, the proof will be worthless and if shown to a trust root this bad proof will result in distrust of the log's operator. That's likely a six or seven figure investment thrown away, for each time this happens.

On the other hand if they do log it, everybody can see what was issued and when, which is inconvenient if you'd prefer to be subtle like the NSA and to some extent Mossad. If you're happy to advertise that you're the bad guys, like the Russians and North Koreans, you do have the small problem that of course nobody trusts you, so, you can't expect any co-operation from the other actors...

Yes, CT makes any sort of certificate issuance attack relatively "loud", but as you seem to be aware that doesn't actually stop the attack from happening in the first place unless the attacker cares about keeping it a secret.

This isn't like a missisuance where you can blame the CA and remove them from the root stores; they'd just be following the normal domain validation processes prescribed in the BRs.

The loudness means that when people yell "The government are doing X" you can go see for yourself, are they doing X? No? So what was the yelling about?

Going to Portland to check whether it's on fire would be a lot of effort - so to some extent I must take it on trust that it's not actually on fire despite Donald Trump's statement - whereas visiting crt.sh to check for the extra certificates somebody claims the US government issued is trivial.

You wouldn't necessarily know whether the certificates were obtained by the US government or another random attacker. They have the CA's name on them and the website name, not the attacker's name.

I'm not saying there's no value in being able to detect when you're compromised. I'm just saying it would be better if the compromise wasn't possible to begin with.

I'd be interested in technology to avoid being compromised if there was much evidence of compromise.

When I looked at this ~10 years ago it was overwhelmingly "Fuck it they'll click past the warning" and today that doesn't work† but I don't work in an industry where it's my job to go find out what's happening to valuable targets (in that case military and government systems, typically in Asia or Africa) any more.

† There are more obstacles, more awareness, and better tooling so "doesn't work" is over-stating it but I'd be very surprised if "fuck it" (ie just don't get certificates and impersonate an HTTP-only site instead) was enough today.

They just MITMed on the link between the victim and it's immediate next hop, most likely by coercing the ISP (OVH). (See the writeup, where the admin discusses TTL values). No amount of multiview is sufficient if you control the uplink. Both DNS resolution and IP routing worked fine and IP packets were intercepted in attacker-controlled envirenment (on-path MITM box).

What would somewhat help would be CAA record with specified ACME account key. The attackers would then have to alter DNS record, would be harder as you describe. (Or pull the key from VM disk image, which would cross another line).