Thanks for the review
On 06/04/2026 19:40, Aaron Gable wrote:
On Sat, Apr 4, 2026 at 6:47 PM zandoodle <[email protected]> wrote:
1. An attacker sets up an ACME server and convinces the client to use
it, the client is then provided the attacker's ACME account on the CA's
domain and instructs the client to setup dns-persist-01 under the
attacker's account.
2. An attacker sets up an ACME server and convinces the client to use
it, the client is then provided the attacker's ACME account for the
attacker's domain and instructs the client to setup dns-persist-01 under
the attacker's account. This requires that the certificate authority allows
accounts to be created under the attacker's domain e.g. creating the
account under the domain in the Host header field as done by Let's Encrypt.
A few notes here:
First, these two scenarios are essentially identical. In both of them, the
attacker is merely providing an attacker-controlled account URI to the
victim client, to get them to populate it in a DNS record. The only
difference with the second scenario is that the victim client operator
would see that their directory URL and account URL have the same domain
name, and might be less likely to notice that something weird is going on.
Second, the second of these scenarios doesn't actually work, at least not
against Let's Encrypt. Although we reflect the Host: header in API
responses, we only respect the *canonical* AccountURI for the purpose of
CAA and dns-persist-01 accounturi=. A client that populates a TXT record
with `accounturi=malicious.ca/acme/acct/12335` would not be able to
complete validation.
I've since found where that's implemented in Boulder and it appears to
sufficiently protect against the second attack, the canoncalisation is
also performed for the dns-account-01 challenge, has this already been
discussed?
Finally, the fundamental threat model here was already considered and
mitigated in RFC 8555. One can imagine a similarly-positioned malicious
ACME proxy-esque server which intercepts an HTTP-01 challenge and replaces
the `token` with one of its own. However, the attacker still can't get the
victim client to successfully complete validation because the necessary
value presented by the client to complete the challenge consists of
*two* pieces
of information: the token (provided by the server) and the Key
Authorization (computed directly by the client). The victim client can't be
fooled into computing a Key Authorization for the malicious proxy's key.
So the solution here is to do the same. The dns-persist record should
contain a piece of information computed directly by the client, rather than
merely provided by the (potentially malicious) server. So I agree
with Sebastian's suggestion that the record format should support an
`accountkey=` parameter.
Aaron
Using the account's public key in the DNS record would prevent both
attacks however I'm not sure what the security implications would be
from discouraging key rollovers.
What I had proposed in another reply
(https://mailarchive.ietf.org/arch/msg/acme/eMmmT1yr6cAOAWYZ5dyZN8Y9ufs/)
was an CA controlled endpoint (such as the account URI) alongside a
token parameter fetched from the CA controlled endpoint. This would make
the client verify that its key is valid for its account with the CA over
HTTPS, the token parameter wouldn't be strictly necessary however it
would demonstrate to the CA that the client has verified their key.
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
