2016-01-26 2:48 GMT+01:00 Hugo Landau <[email protected]>: > 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
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
