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

Peter Eckersley <pde@eff.org> Tue, 22 September 2015 21:53 UTC

Date: Tue, 22 Sep 2015 14:52:58 -0700
From: Peter Eckersley <pde@eff.org>
To: "acme@ietf.org" <acme@ietf.org>
Message-ID: <20150922215258.GJ17243@eff.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE_LNhnt0d8U>
Subject: [Acme] ACME vulnerabilities in SimpleHTTP and DVSNI due to common webservers' default virtual host semantics
Precedence: list

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] 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