Hacker News Reader

Comment by woodruffw | Hacker News Reader

I don’t think a MITM would be sufficient to fool ACME. As Let’s Encrypt’s guide explains[1], an attacker in the middle would still fail to possess the target’s private key. As a result, the proof of possession check would fail.

The attacker could sign with their own key instead, but this is trivially observable to the target (they don’t end up with a correct cert, and it all gets logged in CT anyways.)

[1]: https://letsencrypt.org/how-it-works/

View on HN

If you have a full MITM (you can do anything you like with all traffic to/from the target), you just do your own ACME validation with the target's domain without involving the target at all. Then you use that to MITM the SSL on any connections to the target (terminate SSL between the other side and your middlebox, then push the plaintext into your target, which is unaware anything has changed at all).

If the owner watches CT logs they will know about it (and you may need to jump through some more hoops once the target tries to renew their cert), but you get a lot of info in the meantime.

Sure, but this has nothing to do with ACME itself. The attack model here is "if the attacker is effectively in control of the domain, then they can demonstrate that control." That's a way stronger posture than being able to maliciously MITM a specific ACME session, which (I think) is what the original concern was.

However, even with the full MITM here, this attack assumes that the attacker can proxy plaintext to the host. I'm not aware of many sites that allow sensitive actions (e.g. logging in) over HTTP anymore.

(And, as you note, this is detectable via CT. But it's fair to point out that many/most smaller operators probably aren't bothering to monitor public CT logs for unexpected issuances.)

The attacker could just proxy the plaintext by issuing HTTPS requests to the backend server instead of issuing HTTP requests.

Also, what threat model does SSL protect against that doesn’t involve an attacker in control of a hop in the path between the client and the server?

> The attacker could just proxy the plaintext by issuing HTTPS requests to the backend server instead of issuing HTTP requests.

Yes, assuming the target has HTTPS. The context I originally assumed was one where the target doesn’t yet have a certificate and is using ACME to obtain one.

Separate from that, I agree that an attacker with the ability to demonstrate domain control can subvert issuance in a way that only CT, stapling, and other “post hoc” methods can detect.

Would the target get notified by LetsEncrypt about this scenario though? Let's say I setup Certbot on my server. I'm not watching CT logs. How would I know about the double issuance?

I don’t think it would be a double issuance; it’d be either a failed issuance or a single issuance with a single unexpected key. In other words: the target would end up with in an error state, and they could use CT to determine what happened.

What if they're getting a new certificate and proxying the traffic? As long as the cert looks okay to the end user, they're not going to notice for a while.

Perhaps I’m misunderstanding what you’re saying, but this still doesn’t break the scheme: an attacker who interposes on ACME with their own private key is going to result in a CSR response for the wrong private key being sent back to the target server, which should cause an alertable failure. Even if this is somehow not checked (this would be a serious vulnerability in an ACME client!), the targeted server would end up serving a certificate that it can’t actually use (because it doesn’t have the private half).

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.

[1]: https://news.ycombinator.com/item?id=37567200

Yes, it is the same. I agree, it is not ACME's fault, ACME just makes it simpler due to the automation.

ACME doesn’t require control over the DNS record though. It has a mode where it issues a challenge and you put it on port 80 of your web server.

The DNS based attack would be harder than doing that, for, say, a malicious cloud vendor to implement.

Also, you don’t need a private key to bootstrap a new domain with a new ACME provider.

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.)

Reply on news.ycombinator.com