I had a hard time un-packing this for a minute so I want to try and clarify.
The part about proving to Let's Encrypt is problematic for sites that do not already have TLS on the example.com domain. Any plain HTTP request that Let's Encrypt makes to example.com to validate that you've put up some content on the server is susceptible to a MITM attack. I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.
The MITM problem with requests to example.com doesn't exist if example.com is already set up for HTTPS, which is probably why the examples on the technical description show requests for https://example.com/8303. I was confused about that at first because Let's Encrypt is largely targeted towards people without any TLS encryption yet.
> I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.
FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.
Not sure how the self-signed cert would make things better. Couldn't an MITM attacker do the exact same thing? Presumably, the MITM attacker would already be the party making the (fraudulent) request to the CA, so they could submit their own fingerprint.
I suppose you're correct, I wasn't thinking that the attacker would also submit the request. I guess if you're MITMing CA requests you're screwed anyhow.
I don't see how using TLS would prevent MITM in this case. TLS only prevents MITM if you know public key or if it's been signed by a CA, but neither is the case here.
If something could "just" prove identity without worrying about MITM we would not need the whole RSA stuff.