Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

"Gerd v. Egidy" <gerd.von.egidy@intra2net.com> Fri, 12 January 2018 17:21 UTC

Return-Path: <gerd.von.egidy@intra2net.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 AB4AE12D84D for <acme@ietfa.amsl.com>; Fri, 12 Jan 2018 09:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vw-Mn6H4A8gg for <acme@ietfa.amsl.com>; Fri, 12 Jan 2018 09:21:08 -0800 (PST)
Received: from rp02.intra2net.com (rp02.intra2net.com [62.75.181.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBE812D856 for <acme@ietf.org>; Fri, 12 Jan 2018 09:21:03 -0800 (PST)
Received: from mail.m.i2n (unknown [172.17.128.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rp02.intra2net.com (Postfix) with ESMTPS id 254FA100183; Fri, 12 Jan 2018 18:21:02 +0100 (CET)
Received: from localhost (mail.m.i2n [127.0.0.1]) by localhost (Postfix) with ESMTP id F18455AC; Fri, 12 Jan 2018 18:21:01 +0100 (CET)
X-Virus-Scanned: by Intra2net Mail Security (AVE=8.3.48.112,VDF=8.14.37.110)
Received: from thunder.m.i2n (thunder.m.i2n [172.16.1.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: smtp-auth-user) by mail.m.i2n (Postfix) with ESMTPSA id 6EBF9456; Fri, 12 Jan 2018 18:21:00 +0100 (CET)
From: "Gerd v. Egidy" <gerd.von.egidy@intra2net.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: acme@ietf.org
Date: Fri, 12 Jan 2018 18:21:00 +0100
Message-ID: <2514105.li6vvifsPI@thunder.m.i2n>
Organization: Intra2net AG
In-Reply-To: <20180112170847.GB31935@LK-Perkele-VII>
References: <1812883.r3FRolLa0t@thunder.m.i2n> <4181164.OuRzJEQIXO@thunder.m.i2n> <20180112170847.GB31935@LK-Perkele-VII>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/C8mW3kjDtLXlscvcg2FX1-Kg3tQ>
Subject: Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization
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 17:21:12 -0000

> > I think you also need:
> > 
> > - A user is able to trick the server into serving his document root as
> > default vhost
> > 
> > - The webserver serves the default tls vhost, even if the CA requested a
> > specific vhost via SNI
> 
> Well, I think both are impiled by default vhost.

The first yes.

But the second I'm not so sure.

AFAIK, with Apache httpd you'll get the tls default vhost just for requests 
without SNI.

Of course not everyone is using Apache, but I think it makes it an additional 
condition for the attack to work.

> > > (And there are countermeasures that can detect default vhosts).
> > 
> > Could you explain in more detail?
> > 
> > Will they still work in conjunction with TLS and SNI?
> 
> One trick: Use some wild host value, and see that either TLS handshake
> fails with alert 112, or that returned certificate is different.

Did you (or anybody else) see any setup where that check gives the wrong 
results?

Kind regards,

Gerd