Subject: [Acme] Predictability of http-01 challenge response

From: Hugo Landau <[email-masked]>
Date: Tue, 26 Jan 2016 01:48:34 +0000

Someone pointed out to me that the http-01 challenge can be satisfied
using no knowledge other than the account fingerprint.

For example, as an nginx config:

  location ~ "^/\.well-known/acme-challenge/(-_a-zA-Z0-9]+)$" {
    default_type text/plain;
    return 200 "$1.ACCOUNT_THUMBPRINT";
  }

Was this an intended design feature of the http-01 challenge?

Perhaps more pertinently I should ask, is this property desirable?

This reduces the http-01 challenge to what is essentially an account key
nomination, alebit with a random token (probably needed to satisfy CA/B
forum requirements). I've previously suggested that e.g. the DNS
challenge be changed similarly. In that regard it's quite convenient.
I'm just mildly worried that this property doesn't seem to have been
particularly noticed or discussed, in terms of its security properties.

Musing a little, if this property was deemed desirable, the possibility
of multiple account keys could be better accommodated by including say,
a hash of the account key thumbprint in the URL. Reasoning: The response
value shouldn't match the request value to guard against webservers
which for some reason echo everything they see. A hash of an account key
thumbprint is sufficient to identify an account amongst a list of known
accounts, for the purposes of determining which account an ACME server
is soliciting an endorsement for.

OTOH if this property was deemed undesirable the token in the URL could
be hashed; the response would then prove the server knew the token.

Hugo Landau

---

From: Niklas Keller <[email-masked]>
Date: Tue, 26 Jan 2016 11:58:50 +0100

> be hashed; the response would then prove the server knew the token.

The challenge is to provide the payload on a specific host, not to know
some random token.

If a server knows the account finger print, it can solve challenges made to
it, but that doesn't help to get certificates for other hostnames.

Regards,
Niklas Keller

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 26 Jan 2016 12:41:13 -0800

> Was this an intended design feature of the http-01 challenge?
I think it was not specifically intended or discussed.
> Perhaps more pertinently I should ask, is this property desirable?
The main property we want from challenges is that they are unlikely to
be satisfied accidentally by a party other than the requester. I believe
that's the main value of random tokens as challenges. It's extremely
unlikely that someone will unintentionally have a file on their server
matching the random token.

It's likely that some people using Let's Encrypt will use the sort of
automated response you described, so they could unintentionally response
with a challenge they did not intend to make. However, the inclusion of
the account key thumbprint would ensure that they are not authorizing an
account other than their own.

> particularly noticed or discussed, in terms of its security properties.
I think treating challenges as account key nominations is valuable and
has the potential to make repeated challenge fulfillment easier. But
you're right, we should document the specific security properties that
the DV challenges are intended to provide.
> a hash of the account key thumbprint in the URL.
This is an interesting idea, but I think if we want to go further down
this road, it makes more sense to have a challenge that returns all
account keys that the subscriber considers to be authorized for issuance
on the requested domain.