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]
