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
- [Acme] ACME vulnerabilities in SimpleHTTP and DVS… Peter Eckersley
- Re: [Acme] ACME vulnerabilities in SimpleHTTP and… Richard Barnes
- Re: [Acme] ACME vulnerabilities in SimpleHTTP and… Andrew Ayer
- Re: [Acme] ACME vulnerabilities in SimpleHTTP and… Peter Eckersley
- Re: [Acme] ACME vulnerabilities in SimpleHTTP and… Peter Eckersley
- Re: [Acme] ACME vulnerabilities in SimpleHTTP and… Michael Richardson
- Re: [Acme] ACME vulnerabilities in SimpleHTTP and… Peter Eckersley
- Re: [Acme] ACME vulnerabilities in SimpleHTTP and… Michael Richardson