Re: [Acme] Fixing the TLS-SNI challenge type
Peter Eckersley <pde@eff.org> Fri, 12 January 2018 03:23 UTC
Return-Path: <pde@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C4127337 for <acme@ietfa.amsl.com>; Thu, 11 Jan 2018 19:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.03
X-Spam-Level:
X-Spam-Status: No, score=-7.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 p76Z_P76Vfkx for <acme@ietfa.amsl.com>; Thu, 11 Jan 2018 19:23:14 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7489126E64 for <acme@ietf.org>; Thu, 11 Jan 2018 19:23:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Sender:In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=MqazWVbDUzEIPCNC6n8oQZGXEIu1gAlPp+//KAszfJs=; b=2K02ZUrgueujsw/npL7VMl2H0/8RqVbLMYAcnOPlXwnoH0b7zIi8VAgPzuubBStBCo39QBhvaRAP0qdRawoAsRfioj1lQ1WFZfneFup9p/EY1Cxwgm0trTpMje31rYBGSkSP2f3lNm+IABPN+QYL6fO0FROuMJAw4joTJjLnYSg=;
Received: ; Thu, 11 Jan 2018 19:23:08 -0800
Date: Thu, 11 Jan 2018 19:23:11 -0800
From: Peter Eckersley <pde@eff.org>
To: Roland Bracewell Shoemaker <roland@letsencrypt.org>
Cc: Jonathan Rudenberg <jonathan@titanous.com>, IETF ACME <acme@ietf.org>
Message-ID: <20180112032311.GA28288@eff.org>
References: <FC8545A9-4D43-4BCC-ADB1-40A0F92461E8@titanous.com> <F2551BE5-0866-4F03-972E-E223E8D60001@letsencrypt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F2551BE5-0866-4F03-972E-E223E8D60001@letsencrypt.org>
Sender: pde@eff.org
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/-oisSA6ZfHxbQ5N38XCxATiZiLA>
Subject: Re: [Acme] Fixing the TLS-SNI challenge type
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
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, 12 Jan 2018 03:23:17 -0000
On Thu, Jan 11, 2018 at 04:49:45PM -0800, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. Given that blindly responding to an unknown ALPN value would be an RFC violation this seems safe (although, hey, who knows what servers/cloud providers actually do). Definitely interested in the results of the scan. There could still be some argument about ‘misuse’ of the SNI extension but unless we have a concrete reason to the host name being validated I’m not sure I’m convinced we should. > > Does anyone have any objections/spot any major issues with doing this? I don't have any objections at this stage, but one thing to bear in mind is what will be required to set the ALPN values from various places. There's some support for using it to negotiatie HTTP/2 in Apache 2.4.17+ and Nginx (apparently?) 1.9.5. Even if it's settable from their config files, we'll still need to migrate a lot of Certbot Apache and Nginx plugin users over to HTTP-x Challenge types. And though this is unlikely we should think hard about any ways that malicious actors might be able to set these values :) Also CC'ing Stefan Eissing to get an opinion on the impact on built-in Apache ACME support... > > > On Jan 11, 2018, at 2:41 PM, Jonathan Rudenberg <jonathan@titanous.com> wrote: > > > > As many of you are probably aware, Frans Rosén of Detectify discovered a method of exploiting many shared hosting providers to obtain unauthorized certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt is in the process of removing support for these challenge types[1]. > > > > Obviously this is not ideal, as the TLS-SNI challenge is useful in a variety of use cases. The good news is that TLS-SNI-02 appears to be fixable. > > > > In order to get the ball rolling on a fixed version (aka TLS-SNI-03), here’s a straw proposal, based on something originally publicly suggested by Ryan Sleevi[2]: > > > > Start with the TLS-SNI-02 challenge specification, and add the requirement that the ACME server MUST send an ALPN extension in the ClientHello with a single “acme” protocol name, and the ACME server MUST confirm that the ServerHello also includes an ALPN extension with a single “acme” protocol name. > > > > The only concern I’ve seen about this is the theoretical possibility that servers might just repeat back the ALPN extension with the same protocol name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or similar) to see if this behavior exists in the wild. > > > > Jonathan > > > > [0] https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 > > [1] https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 > > [2] https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme -- Peter Eckersley pde@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
- [Acme] Fixing the TLS-SNI challenge type Jonathan Rudenberg
- Re: [Acme] Fixing the TLS-SNI challenge type Roland Bracewell Shoemaker
- Re: [Acme] Fixing the TLS-SNI challenge type Jonathan Rudenberg
- Re: [Acme] Fixing the TLS-SNI challenge type Roland Bracewell Shoemaker
- Re: [Acme] Fixing the TLS-SNI challenge type Peter Eckersley
- Re: [Acme] Fixing the TLS-SNI challenge type Martin Thomson
- Re: [Acme] Fixing the TLS-SNI challenge type Jonathan Rudenberg
- Re: [Acme] Fixing the TLS-SNI challenge type Martin Thomson
- Re: [Acme] Fixing the TLS-SNI challenge type Matthew D. Hardeman
- Re: [Acme] Fixing the TLS-SNI challenge type Matthew D. Hardeman
- Re: [Acme] Fixing the TLS-SNI challenge type Ilari Liusvaara
- Re: [Acme] Fixing the TLS-SNI challenge type Jonathan Rudenberg
- Re: [Acme] Fixing the TLS-SNI challenge type Patrick Figel
- Re: [Acme] Fixing the TLS-SNI challenge type Matthew D. Hardeman
- Re: [Acme] Fixing the TLS-SNI challenge type Matthew D. Hardeman
- Re: [Acme] Fixing the TLS-SNI challenge type Matthew D. Hardeman
- Re: [Acme] Fixing the TLS-SNI challenge type Ilari Liusvaara
- Re: [Acme] Fixing the TLS-SNI challenge type Niklas Keller
- Re: [Acme] Fixing the TLS-SNI challenge type Daniel McCarney
- Re: [Acme] Fixing the TLS-SNI challenge type Daniel McCarney
- Re: [Acme] Fixing the TLS-SNI challenge type Ilari Liusvaara
- Re: [Acme] Fixing the TLS-SNI challenge type Richard Barnes
- Re: [Acme] Fixing the TLS-SNI challenge type Ilari Liusvaara
- Re: [Acme] Fixing the TLS-SNI challenge type Tim Hollebeek
- Re: [Acme] Fixing the TLS-SNI challenge type Tim Hollebeek
- Re: [Acme] Fixing the TLS-SNI challenge type Ilari Liusvaara
- Re: [Acme] Fixing the TLS-SNI challenge type Salz, Rich
- Re: [Acme] Fixing the TLS-SNI challenge type Tim Hollebeek