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

[Niklas Keller <[e-mail]>]

2016-01-26 2:48 GMT+01:00 Hugo Landau <[e-mail]>:

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

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