[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/
- [Acme] tls-sni-01 validation compromise Jehiah Czebotar
- Re: [Acme] tls-sni-01 validation compromise Martin Thomson
- Re: [Acme] tls-sni-01 validation compromise Martin Thomson
- Re: [Acme] tls-sni-01 validation compromise Jehiah Czebotar
- Re: [Acme] tls-sni-01 validation compromise Peter Eckersley
- Re: [Acme] tls-sni-01 validation compromise Thomas Lußnig