Comment by cyberax
6 hours ago
> I'm not sure precisely what you mean by "MITM on the server side".
For the vast majority of Let's Encrypt certs, you only need to transiently MITM the plain HTTP traffic between the server and the rest of the net to obtain the certificate for its domain. There will be nothing wrong in the CT logs, just another routine certificate issuance.
It is possible to limit this with, yes, DNS. But then we're back to square one with DNS-based security. Without DNSSEC the attacker can just MITM the DNS traffic along with HTTP.
Google, other browser makers, and large services like Facebook don't really care about this scenario. They police their networks proactively, and it's hard to hijack them invisibly. They also have enough ops to properly push the CAA records that will likely be visible to at least one point-of-view for Let's Encrypt.
To detect the misissuance you would run something that compares the certs requested by the server with the certs actually issued and included in the log. If you don't care (and most people don't) then you don't detect it.
No?
With DNSSEC, the public key is communicated to the top-level domain registry through out-of-band means. Presumably over a secure TLS link that can't be MITM-ed. The hash of the public key ("DS record") is, in turn, signed by the TLD's key. Which in turn is signed by the well-known root zone key.
So the adversary won't be able to fake the DNSSEC signatures, even if they control the full network path. They need to compromise your registry, at the very least.
It's how you detect something wrong in the CT logs, not just a routine certificate renewal