While LE is indeed vulnerable to this kind of (difficult) attack, I wanted to make the point that LE still represents, for the most part, an improvement over the previous norms in the CA industry. ACME standardizes automated domain ownership validation to a relatively small number of options that have received relatively rigorous security review (leading to one being dropped due to security concerns, for example).
In contrast, incumbent low-budget CAs have often been a bit of a wild west of automated validation methods, often based on email, that can and do fall to much simpler attacks than a large-scale on-path attack. While CA/B, Mozilla, and others have worked to improve on that situation by requiring CAs to implement more restrictive policies on how domains can be validated, ACME still represents a much better validated, higher-quality validation process than that offered by a number of major CAs for DV certificates.
One approach to decentralized or at least compromised-CA-tolerant TLS is something called "perspectives" (also implemented as "convergence"). The basic concept is that it's a common attack for someone to intercept your traffic, but it's very difficult for someone to intercept many people's traffic on the internet. So, if the TLS certificate and key you receive from a website is the same as the one that many other people have received, it is most likely genuine. If it's different, that's an indicator of a potential on-path attack. This can be implemented by establishing trust between your computer and various "notaries" which basically just check the certificate from their perspective and confirm that it matches yours.
I bring this up, because if you squint just right you can view ACME as being a method of bolting the same concept onto the existing CA infrastructure: before you connect to a website, LetsEncrypt acts as a notary by connecting to the domain from multiple perspectives and ensuring that the same person evidently controls it from all of them. While not perfect, this is a strong indicator that the person requesting the cert is legitimate.
The on-path attack risk is almost, but not always, on a late stage of the network path to the user (e.g. their local network). The big weakness of the ACME approach is an interception of a late stage of the network path to the server. This tends to be much better secured, but hey, it's still something to worry about. There is obviously also a reliance on DNS, but I would say that DNS has basically always been the most critical single link in on-path attack protection.
In contrast, incumbent low-budget CAs have often been a bit of a wild west of automated validation methods, often based on email, that can and do fall to much simpler attacks than a large-scale on-path attack. While CA/B, Mozilla, and others have worked to improve on that situation by requiring CAs to implement more restrictive policies on how domains can be validated, ACME still represents a much better validated, higher-quality validation process than that offered by a number of major CAs for DV certificates.
One approach to decentralized or at least compromised-CA-tolerant TLS is something called "perspectives" (also implemented as "convergence"). The basic concept is that it's a common attack for someone to intercept your traffic, but it's very difficult for someone to intercept many people's traffic on the internet. So, if the TLS certificate and key you receive from a website is the same as the one that many other people have received, it is most likely genuine. If it's different, that's an indicator of a potential on-path attack. This can be implemented by establishing trust between your computer and various "notaries" which basically just check the certificate from their perspective and confirm that it matches yours.
I bring this up, because if you squint just right you can view ACME as being a method of bolting the same concept onto the existing CA infrastructure: before you connect to a website, LetsEncrypt acts as a notary by connecting to the domain from multiple perspectives and ensuring that the same person evidently controls it from all of them. While not perfect, this is a strong indicator that the person requesting the cert is legitimate.
The on-path attack risk is almost, but not always, on a late stage of the network path to the user (e.g. their local network). The big weakness of the ACME approach is an interception of a late stage of the network path to the server. This tends to be much better secured, but hey, it's still something to worry about. There is obviously also a reliance on DNS, but I would say that DNS has basically always been the most critical single link in on-path attack protection.