Re: [Acme] ACME vulnerabilities in SimpleHTTP and DVSNI due to common webservers' default virtual host semantics

Richard Barnes <rlb@ipv.sx> Thu, 24 September 2015 01:19 UTC

Return-Path: <rlb@ipv.sx>
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 5E6CF1B349F for <acme@ietfa.amsl.com>; Wed, 23 Sep 2015 18:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 LjNxEQztO7QW for <acme@ietfa.amsl.com>; Wed, 23 Sep 2015 18:19:22 -0700 (PDT)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BC11B349D for <acme@ietf.org>; Wed, 23 Sep 2015 18:19:22 -0700 (PDT)
Received: by lacao8 with SMTP id ao8so47340353lac.3 for <acme@ietf.org>; Wed, 23 Sep 2015 18:19:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6YXGjEmip9kz+xiOSIFrbhfEC/JnK5q5GiL5dPnSnc4=; b=bO9pPuj8Ths1UUk6lcYLUqahXc+LmaT2kxN/JbxEi/FLJLdRdY8uPNYUWLN4M/8+7d 13e/sf0HfKWDcMZgs0ld3DlLnCoO9DusULh3CQ21pYaUce4y0XjsieL7duRkjO2t37yz zPKKQt9D1+OKQDE1lrmisLDB4vsnX8ZVfqT3GWwA56+lm0PI5HAWTDe2UJfXAxfKs+qp AfZdsr9hHmE8aIiBQF5xtUzogPGo1DTTTTgfrgTaHzpkTBtecKHcL1KeYacAZ84xhcwM 9SCYdzz+weOsKDdUVHezHSidFcXIt4hXD00EHvQgv+MvIj8hU042hY8SY6m5+ms7TVUt eByg==
X-Gm-Message-State: ALoCoQkW/G1xxM2kiR0Y4U9DfyHR7Km7sUxwD3pGBbiFFBUDaw9pZ56S9kEM6rY9wpqC+6YMHxqw
MIME-Version: 1.0
X-Received: by 10.152.1.162 with SMTP id 2mr12430703lan.61.1443057559797; Wed, 23 Sep 2015 18:19:19 -0700 (PDT)
Received: by 10.25.157.211 with HTTP; Wed, 23 Sep 2015 18:19:19 -0700 (PDT)
In-Reply-To: <20150922215258.GJ17243@eff.org>
References: <20150922215258.GJ17243@eff.org>
Date: Wed, 23 Sep 2015 18:19:19 -0700
Message-ID: <CAL02cgTaaaEtX1mcLrP6fxqMp_Q+9y+f+E0DYFedzMaJ5nXDRw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Peter Eckersley <pde@eff.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/rF8w4oHIvXUUVND8fJ59952DcLg>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] ACME vulnerabilities in SimpleHTTP and DVSNI due to common webservers' default virtual host semantics
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: Thu, 24 Sep 2015 01:19:24 -0000

I have to admit that I'm not super sanguine about fixing this.  On the
one hand, hosting providers will always be a point of vulnerability
for automated verification that uses control of a named host -- the
hosting provider controls the whole stack for the domain, after all.
So it seems a little quixotic to chase after vulnerabilities at the
hosting provider.  On the other hand, it does seem good to address
obvious, likely ways that a provider could *accidentally* cause
attacks.

I am OK with dropping the TLS option for "simpleHttp" validations.
(We can always make SimpleHTTPS later.)  I haven't really evaluated
the DVSNI fix.




On Tue, Sep 22, 2015 at 2:52 PM, Peter Eckersley <pde@eff.org> wrote:
> Apache (and I gather nginx too) have the subtle and non-intuitive
> behaviour that if a default TLS/HTTPS virtual host is not configured
> explicitly, one will be selected based on the ordering of vhosts in the
> webserver configuration (in practice, this often amounts to alphabetical
> ordering of files in a configuration directory).
>
> https://serverfault.com/questions/458106/apache2-default-vhost-in-alphabetical-order-or-override-with-default-vhost
> https://serverfault.com/a/180956
>
> This creates a vulnerability for SimpleHTTP and DVSNI in any
> multiple-tenant virtual hosting environment that failed to explicitly
> select a default vhost [1].  The vulnerability allows one tenant
> (typically one with the alphabetically lowest domain name -- a situation
> that may be easy for an attacker to arrange) to obtain certificates for
> other tenants.  The exact conditions for the vulerability vary:
>
>  - SimpleHTTP is vulnerable if no default vhost is set explicitly, the
>    server accepts the "tls": true parameter as currently specified, and
>    the domains served over TLS/HTTPS are a strict subset of those served over
>    HTTP.
>
>  - DVSNI is vulnerable if no default vhost is set explicitly, and the
>    hosting environment provides a way for tenants to upload arbitrary
>    certificates to be served on their vhost.
>
> James Kasten and Alex Halderman have done great work proposing a fix for
> DVSNI:
>
> https://github.com/letsencrypt/acme-spec/compare/sig-reuse...pde:dvsni-default-vhost-fix
>
> That fix also has some significant performance benefits on systems with
> many virtual hosts, and the resulting challenge type should perhaps be
> called DVSNI2.
>
> The simplest fix for SimpleHTTP is to remove the "tls" option from
> the client's SimpleHTTP response, and require that the challenge be
> completed on port 80.
>
> https://github.com/pde/acme-spec/commit/2bf0488b9d6386b0d8ee34edfe8ba5829de0d9fa
>
> Alternatively, the protocol could allow the server to specify which
> ports it will perform SimpleHTTP and SimpleHTTPS requests on; HTTPS on
> port 443 SHOULD be avoided unless the CA can confirm that the server has
> an explicitly configured default vhost.
>
> The above diffs are currently against Let's Encrypt's version of the
> ACME spec, we'll be happy to rebase them against the IETF version upon
> request.
>
> [1] though I haven't confirmed it, it's possible that sites that
> attempted to set a default vhost are vulernable if they followed advice
> like this when doing so: https://serverfault.com/a/458181 ; an attacker
> need only sign up with a lexicographically lower name on that hosting
> platform to obtain control of the default.
>
> --
> Peter Eckersley                            pde@eff.org
> Chief Computer Scientist          Tel  +1 415 436 9333 x131
> Electronic Frontier Foundation    Fax  +1 415 436 9993
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme