[Acme] tls-sni-01 validation compromise

Jehiah Czebotar <jehiah@gmail.com> Fri, 22 January 2016 02:38 UTC

Return-Path: <jehiah@gmail.com>
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 948241B369E for <acme@ietfa.amsl.com>; Thu, 21 Jan 2016 18:38:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 0nL0PGbZi2cd for <acme@ietfa.amsl.com>; Thu, 21 Jan 2016 18:38:26 -0800 (PST)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CAB1B369B for <acme@ietf.org>; Thu, 21 Jan 2016 18:38:25 -0800 (PST)
Received: by mail-vk0-x22a.google.com with SMTP id k1so34250104vkb.2 for <acme@ietf.org>; Thu, 21 Jan 2016 18:38:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Kk7y3RKB63Y7/WQjCFoqsel0ZF1fmAFbtrN6fj0hDYc=; b=ZvML/lXKsVtB0YqZlo72UOgAt9r8C2hadFs/bcbjVieGu+6ar/A9fc01fBW+AcfaWL mizncw7npTCa+8SxiLV9CKvjn1+VS2ZVCIUYoM5KK6oCrTIjzKYpKFzlQHubd2aLbUqX NEtrycRxHvwQpp6zDlzQs9B0foifw0LxofG6DoPLyIJAU74X4i2wtloRqvdEgA1o8pRb 4NTT3PYrYmPqHuJ4JEXoeczLTcZRUjp0JCfHDUBZJHHczlmkRpjE5erwVUt81Pw3iyxw r+X/T95JHNBkeQMpLNLvrQeRnrupbRfYKQZXdPF/bW6dWLjTB8w91mHmVMvDhZG3hBvK OeTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Kk7y3RKB63Y7/WQjCFoqsel0ZF1fmAFbtrN6fj0hDYc=; b=FDR9mDJ5gJ7HBUdncTfMuUHu5pNqFTHO+hNppk9c2Sx4rQDbuxwMraPAbqyVBvJHXt 89Vn80ao4gdslviM/Bxdd6V6QaW1Ey5c4G7jM+t2DqEI2Oxnv7Zdx84uR1Zvl0E2oW+F /Hfc441KCfanf2op2UIXRLNXPEscuQuJN/zgAIqfCWHNOflPqPHc4MU+tbbxvxizB+yI CIQoOL6+PBWnAotOSUlQvhivc/MEMcv9KAWZOgXf1RWaagXDXj2te4aupO8PQSzsLOuE Hw0dMefeNibajpR8mYZMeQyxClBcgVtVGPx731LoS74FRZ1nc9oJpK53Fz8NLH1E0khb 1exw==
X-Gm-Message-State: AG10YOQySqWPR9z7pxTL2PJDyM843+viWOUAwRmI5sGoQU6aRppTse7vgcn0ef0Y+dd3vLRj4CwGawmKd/oYvg==
MIME-Version: 1.0
X-Received: by 10.31.170.196 with SMTP id t187mr406368vke.66.1453430304891; Thu, 21 Jan 2016 18:38:24 -0800 (PST)
Received: by 10.31.92.77 with HTTP; Thu, 21 Jan 2016 18:38:24 -0800 (PST)
Date: Thu, 21 Jan 2016 21:38:24 -0500
Message-ID: <CAES3dxRZ7ieQ+G0Zv0oZmehUFPGU36KUdvrkSL+MMLSQWbP08w@mail.gmail.com>
From: Jehiah Czebotar <jehiah@gmail.com>
To: acme@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/s8gaZ6ev-iqoSQjOZWUpZ41mA0M>
Subject: [Acme] tls-sni-01 validation compromise
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: Fri, 22 Jan 2016 02:40:46 -0000

In working to implemented LetsEncrypt at Bitly, I uncovered an issue
with the tls-sni-01 validation that limits its trustworthiness in
validation.

Issue:

The tls-sni-01 validation is intended to prove control over a domain
name. The challenge relies on presenting a
"<Zi[0:32]>.<Zi[32:64]>.acme.invalid" as the ServerName in the
clientHello, and relying on a self-signed certificate to used to
complete the TLS handshake that has a single matching
subjectAlternativeName/DNSName.

Because the server initiating the validation request is presenting the
full ServerName expected back, it is thus untrusted and can not be
used to imply any relation to the party requesting validation. It is
possible to configure a server that generates certificates on-the-fly
to match the ServerName presented, and thus passing ALL tls-sni-01
validation attempts. An example of such a server is
https://gist.github.com/jehiah/a5b508b8f4efad08e67a

Suggestions:

1) Change the requirement that the self signed cert have one DNSName,
and require the response to have TWO DNS names. One that matches the
requested hostname, and a second that is secret which proves it can
only be created by the appropriate party initiating validation
2) Remove reliance on SNI matching, and make the challenge `tls-01`
and fulfill the same HTTP response requirements as `http-01` where the
Hostname, and request path are untrusted, but the response body with
full keyAuthorization proves the connection to the requestor. This
opens up the possibility of TLS validation against the $domain being
validated instead of relying on a .acme.invalid hostname.

Other Notes:

There appear to have been discussions about `n` versions of
certificates being generated and requiring validation to check a
subset of them. I think this vulnerability means `n` is moot as no
number of checks for certificates that match the server hello prove
control over a domain name.

Thoughts?

p.s. Thank you to Richard Barnes from Mozilla for pointing me to this
mailing list.

-- 
Jehiah
http://jehiah.cz/