That would prevent attack 1 (Attacker controlled account on CA's origin)
however it could also allow the attacker to return their CA account URI
(or whatever was provided in the account) for an account (not registered
with the CA) on the attacker's origin.
Maybe it should be a token alongside the account URI, e.g.
_validation-persist TXT
"letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acct/123456;token=<persist-token-from-account-api>".
This would provide proof to the issuing CA that the client has verified
their key for their account for which the success response was protected
by HTTPS.
On 05/04/2026 14:54, Seo Suchan wrote:
For this spicific attack As this accounturi doesn't change between
challenge domains, can we move it inside of actual account endpoint?
If client need to use actual accounturi they'd found it can't use that
accounturi because is doesn't have publickey for that account.
In general if you want cryptopical binding you'd need to use crypto
key. Don't think full mitm version of this attack can be prevented
while we using accounturi not account public key.
On 2026년 4월 5일 오후 10시 23분 13초 GMT+09:00, zandoodle
<[email protected]> 작성함:
Sorry for the late reply, I couldn't find how to reply to an email
in a mailing list digest in the gmail web client. On 05/04/2026
03:13, Sebastian Robin Nielsen wrote:
Both of these attacks rely on violation of the ”On First
Trust” principle. It works like a SSH key, which you must
verify on first use. You as a domain owner, are supposed to
verify the accounturi is yours, before setting up a
dns-persist-01 record.
I was having the client be provided the attacker's account URI
when they visited the newAccount endpoint which could make the
client think that they owned the attacker's account URI, attack 1
relied on there currently being little reason to make a POST
request to the account URI which appears to be the only way to
verify ownership of an account.
About: ” The first attack could be prevented by having the
client by making a POST request of some sort to the account
URI which allows them to verify that their key is valid for
the account.” If the attacker has control over the
communication, the attacker could replace that communication too.
I was having the attacker not be in control of communications to
the legitimate CA and instead have their own domain e.g.
https://dns-persist-testing.attacker.example, a request to the
account URI under the legitimate CA's domain would still be
protected by HTTPS.
One way to improve the protocol, would be to allow the
accounturi be a SHA256 hash of the public key. Like:
_validation-persist.YOURDOMAIN.TLD 3600 IN TXT
"letsencrypt.org;accounturi=pubkey:
135b12725a113862143f7cc14bfbb56e66eefe86158769f6128e9da9f463998a;policy=wildcard"
This would allow the domain owner to provision the record even
long before the account is created and given an account uri,
which means the generation of the DNS record can happen
locally long before any ACME server on the internet even sees
a internet packet.
It could also discourage ACME clients from implementing an account
key rollover which could make one time access to the account's
private key in to a persistent threat. I know that a key
compromise is already bad, however an account key rollover (which
could be performed regularly) would either regain control or
provide an indication of a compromise for the legitimate system.
*Från:*[email protected]
<[email protected]> *För *zandoodle *Skickat:* den
5 april 2026 03:48 *Till:* [email protected] *Ämne:* [Acme]
Potential issues with dns-persist-01 Hello, IETF participants
I'm somewhat concerned about the lack of binding between an
account's key, the challenge and the certificate request. This
could lead to two new similar attacks against a user's domain.
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.
dns-01, http-01 and tls-alpn-01 all have the client's ACME
account's public key as part of the challenge so the client's
account and the account the certificate authority is issuing
to must be the same. The first attack could be prevented by
having the client by making a POST request of some sort to the
account URI which allows them to verify that their key is
valid for the account. The second attack could be prevented by
the certificate authority by verifying the account-uri is both
https and on a domain they control when verifying/offering the
dns-persist-01 challenge or by restricting the domains under
which an account can be created. Both attacks could also be
prevented by having the client check that the directory,
account URI and issuer domain name have the same domain name
however this might be overly restrictive. The issuer domain
name might not be sufficient protection as the server
instructs the client as to what it should be. Given the strong
security requirements for the issuer domain names including
DNSSEC but with no requirement to resolve the domain names,
maybe the authors intended to put metadata at the issuer
domain names.
------------------------------------------------------------------------
Acme mailing list -- [email protected] To unsubscribe send an email to
[email protected]
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
