Re: [Acme] ALPN based TLS challenge
Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 23 February 2018 14:13 UTC
Return-Path: <ilariliusvaara@welho.com>
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 9A39112E855 for <acme@ietfa.amsl.com>; Fri, 23 Feb 2018 06:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 HqdCBmMDzCTL for <acme@ietfa.amsl.com>; Fri, 23 Feb 2018 06:12:58 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B577512E054 for <acme@ietf.org>; Fri, 23 Feb 2018 06:12:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AAC4945522; Fri, 23 Feb 2018 16:12:55 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id G1NpV7b7QNPL; Fri, 23 Feb 2018 16:12:55 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 38EF779; Fri, 23 Feb 2018 16:12:50 +0200 (EET)
Date: Fri, 23 Feb 2018 16:12:49 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Doug Beattie <doug.beattie@globalsign.com>
Cc: Roland Bracewell Shoemaker <roland@letsencrypt.org>, Rich Salz <rsalz@akamai.com>, IETF ACME <acme@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20180223141249.GA18818@LK-Perkele-VII>
References: <0639F8AA-9E14-4FD4-A9A4-C03EB4D95962@letsencrypt.org> <CABkgnnVgFN57OeuN61rHa9i7teo_TGyA1CNXiQz0n4KcQ=O78Q@mail.gmail.com> <3B21694B-E5D0-4D39-83CE-A7EBD8BF2F48@akamai.com> <01E6B12D-69EE-4104-8E1B-BE1512A1DDCB@letsencrypt.org> <SG2PR0301MB1190E57D534C66731C1E9019F0CC0@SG2PR0301MB1190.apcprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <SG2PR0301MB1190E57D534C66731C1E9019F0CC0@SG2PR0301MB1190.apcprd03.prod.outlook.com>
User-Agent: Mutt/1.9.3 (2018-01-21)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/B7sZq-VQtW4DqBTuaVUlUPuhoU8>
Subject: Re: [Acme] ALPN based TLS challenge
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, 23 Feb 2018 14:13:00 -0000
On Fri, Feb 23, 2018 at 01:17:53PM +0000, Doug Beattie wrote: > I'm probably not understanding a key piece of technical info about the > protocol, but when I see this statement it makes me think it has similar > issues to tls-sni-01. If we're relying on the hosting provider enforcing > certain constraints like this, then we're delegating a critical piece of > domain control back to the hosting provider which would be a no-go. > > 4. Security Considerations > > The design of this challenges relies on some assumptions centered > around how a server behaves during validation. > > The first assumption is that when a server is being used to serve > content for multiple DNS names from a single IP address that it > properly segregates control of those names to the users on the server > that own them. This means that if User A registers Host A and User B > registers Host B the server should not allow a TLS request using a > SNI value for Host A that only User A should be able to serve that > request. If the server allows User B to serve this request it allows > them to illegitimately validate control of Host A to the ACME server. > > Please let me know what I'm missing. The assumption that users can only influence HTTPS names they own probably holds in practice. The entiere security of entiere methods 9 and 10 relies on exactly that. Exploiting TLS-SNI-0x did not require answering for the name in question. What I am more worried about is hosting providers which treat HTTP and HTTPS independent from each other. These are not common, but there are some. And judging from Globalsign ("oneclick") issue, either these hosting provoders are relevant, or everyone just misunderstood the issue. -Ilari
- [Acme] ALPN based TLS challenge Roland Bracewell Shoemaker
- Re: [Acme] ALPN based TLS challenge Martin Thomson
- Re: [Acme] ALPN based TLS challenge Salz, Rich
- Re: [Acme] ALPN based TLS challenge Ilari Liusvaara
- Re: [Acme] ALPN based TLS challenge Roland Bracewell Shoemaker
- Re: [Acme] ALPN based TLS challenge Doug Beattie
- Re: [Acme] ALPN based TLS challenge Ilari Liusvaara
- Re: [Acme] ALPN based TLS challenge Sebastian Nielsen
- Re: [Acme] ALPN based TLS challenge Doug Beattie
- Re: [Acme] ALPN based TLS challenge [invalid sign… Sebastian Nielsen
- Re: [Acme] ALPN based TLS challenge [invalid sign… Doug Beattie
- Re: [Acme] ALPN based TLS challenge [invalid sign… Sebastian Nielsen
- Re: [Acme] ALPN based TLS challenge Salz, Rich
- Re: [Acme] ALPN based TLS challenge Stephen Farrell
- Re: [Acme] ALPN based TLS challenge [invalid sign… Ilari Liusvaara
- Re: [Acme] ALPN based TLS challenge Ilari Liusvaara
- Re: [Acme] ALPN based TLS challenge Roland Bracewell Shoemaker
- Re: [Acme] ALPN based TLS challenge Richard Barnes
- Re: [Acme] ALPN based TLS challenge Daniel McCarney
- Re: [Acme] ALPN based TLS challenge Doug Beattie
- Re: [Acme] ALPN based TLS challenge Ryan Sleevi
- Re: [Acme] ALPN based TLS challenge Doug Beattie
- Re: [Acme] ALPN based TLS challenge Matthew D. Hardeman
- Re: [Acme] ALPN based TLS challenge Salz, Rich
- Re: [Acme] ALPN based TLS challenge Tim Hollebeek