IETF Logo Mail Archive

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:03 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 A3B8312D84D for <acme@ietfa.amsl.com>; Fri, 12 Jan 2018 09:03:40 -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 zF0J1sy_one7 for <acme@ietfa.amsl.com>; Fri, 12 Jan 2018 09:03:38 -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 A10BE127978 for <acme@ietf.org>; Fri, 12 Jan 2018 09:03:38 -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 EB0A4100183; Fri, 12 Jan 2018 18:03:36 +0100 (CET)
Received: from localhost (mail.m.i2n [127.0.0.1]) by localhost (Postfix) with ESMTP id B8F32466; Fri, 12 Jan 2018 18:03:36 +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 0C0D4376; Fri, 12 Jan 2018 18:03:35 +0100 (CET)
From: "Gerd v. Egidy" <gerd.von.egidy@intra2net.com>
To: acme@ietf.org
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Fri, 12 Jan 2018 18:03:34 +0100
Message-ID: <4181164.OuRzJEQIXO@thunder.m.i2n>
Organization: Intra2net AG
In-Reply-To: <20180112164233.GA31841@LK-Perkele-VII>
References: <1812883.r3FRolLa0t@thunder.m.i2n> <20180112164233.GA31841@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/gt_UkoT2ApfpI0ja8wOGarvGqOI>
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:03:40 -0000

> That is still vulernable to default-vhost issues if:
> 
> - The hoster does not explicitly reserve default vhost (I have seen that
>   kind of behavior with http:// too).
> - The hoster lets customers upload arbitrary certificates.

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

> Note that this is strictly stronger condition than the one for TLS-SNI
> vulernability, which only required capability to upload arbitrary
> certificates, but not to control default vhost.

Yes, definitively.
 
> (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?

Kind regards,

Gerd

v2.23.0 | Report a Bug | By Email