Re: [Acme] tls-sni-01 validation compromise

Peter Eckersley <pde@eff.org> Fri, 22 January 2016 19:49 UTC

Return-Path: <pde@mail2.eff.org>
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 24D691B2CDC for <acme@ietfa.amsl.com>; Fri, 22 Jan 2016 11:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 dRvZC8VqkSp9 for <acme@ietfa.amsl.com>; Fri, 22 Jan 2016 11:49:38 -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 0B2C11B2CDA for <acme@ietf.org>; Fri, 22 Jan 2016 11:49:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=3JTBG7cgucfz2dWfnh7oTDsgBq4935oHlJ21tR8Z5pE=; b=YJP2t9iCjDvOlWQE8GvfDySjjD4gKF/cnHVtgBp5iVuybBX/GbbybfeQsZPSmJtNO9qb7HuI6nRG8RaHuNRcAPlHNY81kC4tP5GNsLiobZxBaOMdifxZ/FgUpODizEjJb+qHz4Ay3ZRm18b1Uz39RpVro7t1JrQJ/ah7f91UaDE=;
Received: ; Fri, 22 Jan 2016 11:49:37 -0800
Date: Fri, 22 Jan 2016 11:49:37 -0800
From: Peter Eckersley <pde@eff.org>
To: Jehiah Czebotar <jehiah@gmail.com>
Message-ID: <20160122194937.GN19827@eff.org>
References: <CAES3dxRZ7ieQ+G0Zv0oZmehUFPGU36KUdvrkSL+MMLSQWbP08w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAES3dxRZ7ieQ+G0Zv0oZmehUFPGU36KUdvrkSL+MMLSQWbP08w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/VVH8IYWSbwf9QVBF6i-27hbmEC0>
Cc: acme@ietf.org
Subject: Re: [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 19:49:40 -0000

On Thu, Jan 21, 2016 at 09:38:24PM -0500, Jehiah Czebotar wrote:
 
> 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

This is certainly possible, and a reason to spec tls-sni-02 to fix the
issue.  For purposes of scheduling deprecatio of tls-sni-01, do we know
of any deployed implementations that have done things that way?  Making
the cert in response to the SNI request is usually going to be a bit
more involved, TLS-library-wise, than making it when the socket starts
listening. If nobody has deployed mid-handshake cert generation, we can
be a bit more gradual with the tls-sni-01 deprecation schedule.

-- 
Peter Eckersley                            pde@eff.org
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993