I think you're misunderstanding. Say as an attacker, I am able to get control of the DNS zone for a target. We will assume the site is not using an ACME issued cert, but some other provider.
I am now able to get a new certificate issued with ACME using the DNS-01 challenge. I set up one of my own servers as a proxy, HTTPS terminated with this new cert. I then have it proxy to the existing site (by IP address.) I then change the site's DNS to point to my own server. The users are no wiser, but I am able to intercept all traffic.
Okay, I think I understand what you're saying now: this is similar to the attack described by 'rcxdude here[1].
I interpreted the original comment that started this thread to imply an attack on ACME itself, not the fact that ACME can't detect the difference between someone who legitimately controls a domain and someone who illegitimately controls a domain. As far as I know, that's considered a more general defect in the Web PKI, one that predates ACME substantially.
The HTTP-based challenge is similar in scope to the DNS one: an attacker would still need the target’s private key to actually impersonate the ACME session itself.
Put another way: this is still not an issue with ACME itself, but the fact that the Web PKI is built on top of unauthenticated substrates (primarily DNS). If someone (like your cloud provider) can demonstrate control of your domain, then it is ipso facto their domain as well. ACME can’t solve that any more than the previous generation of DV techniques could.
I understand. I just used the DNS challenge as an example. I generally use the DNS challenge since I can assign certs on my private network more easily (the zone is public.)
I am now able to get a new certificate issued with ACME using the DNS-01 challenge. I set up one of my own servers as a proxy, HTTPS terminated with this new cert. I then have it proxy to the existing site (by IP address.) I then change the site's DNS to point to my own server. The users are no wiser, but I am able to intercept all traffic.