[Acme] Predictability of http-01 challenge response

Hugo Landau <hlandau@devever.net> Tue, 26 January 2016 01:48 UTC

Return-Path: <hlandau@devever.net>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC7A1ACD65 for <acme@ietfa.amsl.com>; Mon, 25 Jan 2016 17:48:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.698
X-Spam-Level:
X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gXS0BzLJouW for <acme@ietfa.amsl.com>; Mon, 25 Jan 2016 17:48:35 -0800 (PST)
Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2711F1ACD5D for <acme@ietf.org>; Mon, 25 Jan 2016 17:48:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 579B11C66D for <acme@ietf.org>; Tue, 26 Jan 2016 02:48:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:content-disposition:content-type:content-type :mime-version:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1453772914; x=1471962275; bh=bduc plBG3uSBRvuqSSM+wR/giX28J2hBjYrVtQ3zdRc=; b=BtqBML7SNoYy6Tzo9p6d 7GBY4kJJgLRK4BxybDpAR4D3aBXAjxbZS8VdePFYNnZvccT+fDax4jN5iCnm143I hU1SmogFXAfpXCDJ5QH8/or+qYWKuS3CS+kXdNgpBfyXD7f0zz2sJ++f8rlqCf8c h0aiO57eQwzdJQbuAVAB3LeeucNWD0GYNN2Y25acKHRuB43D7AFR8JL6LtD/qyw+ 6aQe0WapU1pjKmMWPsQsjwu1B2E7BsEC4bQ0eXl+2lCWEV6cY6VLPYC/xic+zu8n 1MM6GEpOJVJGdJMKBz6rOr+y0pW4ILpoGtcNAdrf98It/L5E+csc2w6jn6WI9FMP Dg==
Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id vHctxBk_hnNf for <acme@ietf.org>; Tue, 26 Jan 2016 02:48:34 +0100 (CET)
Received: from andover (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 2637E1C38C for <acme@ietf.org>; Tue, 26 Jan 2016 02:48:34 +0100 (CET)
Date: Tue, 26 Jan 2016 01:48:34 +0000
From: Hugo Landau <hlandau@devever.net>
To: acme@ietf.org
Message-ID: <20160126014833.GA16635@andover>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/AzbC_ZCoQmD3PScHvJdDFQjg1zA>
Subject: [Acme] Predictability of http-01 challenge response
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2016 01:48:37 -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