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

From: Peter Eckersley <[email-masked]>
Date: Tue, 22 Sep 2015 14:52:58 -0700

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                            [email-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: Richard Barnes <[email-masked]>
Date: Wed, 23 Sep 2015 18:19:19 -0700

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 <[email-masked]> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 23 Sep 2015 21:16:46 -0700

On Wed, 23 Sep 2015 18:19:19 -0700

> obvious, likely ways that a provider could *accidentally* cause

I'm not super sanguine about the fix either, especially given the
complexity it adds to the DVSNI challenge.  It is important to prevent
people from shooting themselves in the foot with misconfigurations, but
this goal has to be balanced against the need for the protocol to be
useful and not too difficult to comprehend and implement.

Also note that non-TLS SimpleHTTP could be vulnerable in the same
fashion, if a hostname resolves to a shared hosting provider and a
virtual host for that hostname is not configured.  This could happen if
the hosting account for that hostname has been terminated but the DNS
hasn't been updated yet.  But it would be pretty counterproductive to
ditch SimpleHTTP just because of this possibility.

> (We can always make SimpleHTTPS later.)

One annoying implication with dropping the TLS option is that it makes
it difficult to complete the SimpleHTTP challenge when your HTTP site
redirects to HTTPS, as best practice dictates.  You'd have to
special-case an exception to allow the challenge response to be served
over HTTP (this is annoying to do in Apache).

This isn't a problem if the ACME server follows redirects when
validating the challenge.  The draft doesn't currently require or
forbid following redirects, so implementations will probably end up
doing whatever their HTTP client library does by default.  Could we
require the ACME server to follow redirects as long as the only change
in the URI is the scheme? This should be safe since, presumably, the web
server would only be configured to serve such a redirect if an HTTPS
virtual host for that hostname was configured.

-- Andrew

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 23 Sep 2015 21:52:34 -0700

On Wed, Sep 23, 2015 at 09:16:46PM -0700, Andrew Ayer wrote:

> doing whatever their HTTP client library does by default. 

Boulder does indeed follow redirects, so that's our current plan.

I don't think it would be a problem to require following them, or at
least N layers of them.

> Could we require the ACME server to follow redirects as long as the
> only change in the URI is the scheme? This should be safe since,
> presumably, the web server would only be configured to serve such a
> redirect if an HTTPS virtual host for that hostname was configured.

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 23 Sep 2015 22:55:52 -0700

> obvious, likely ways that a provider could *accidentally* cause

Although we could argue that this issue is the responsibility of hosting
providers and/or the webserver codebases themselves, the reality is that
this situation is probably not exploitable prior to ACME deployment
(unless one of the current HTTP DV CAs uses HTTPS?).  Rather than
expecting a potentially very large number of deployed systems to change
their behaviour as a result of ACME entering use, it seems more prudent
to design defensively around the behaviour of deployed systems.

> (We can always make SimpleHTTPS later.)  I haven't really evaluated

I believe the simpleHttp fix is urgent -- there are likely to be a lot
of vulnerable servers.  The DVSNI fix may not be as urgent, because only
systems that allow tenants to deploy their own certs would be affected,
but we should definitely include it in any breaking change we're making
to DVSNI, rather than waiting to see if we need to make another breaking
change shortly down the road.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Sep 2015 10:03:03 -0400

{Tourist warning here}

    > Boulder does indeed follow redirects, so that's our current plan.

So, if the verifier follows an HTTP redirect to an HTTPS site (does it even
have to be same name?), which has a (at that point) bogus certificate, and
Boulder can cope with that, when why bother having the SimpleHTTP check
method at all?

Why not just always use SimpleHTTPS?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Peter Eckersley <[email-masked]>
Date: Thu, 24 Sep 2015 09:52:49 -0700

On Thu, Sep 24, 2015 at 10:03:03AM -0400, Michael Richardson wrote:
> have to be same name?), which has a (at that point) bogus certificate, 
> and Boulder can cope with that, when why bother having the SimpleHTTP
> check method at all?
> 

Because it is common for webservers to be configured with HTTPS vhosts
that are a strict subset of the HTTP ones, plus a misallocted
default/wildcard HTTPS vhost that is controlled by the
tenant/hypothetical attacker.

Those vulnerable webservers are unlikely to serve a redirect from HTTP
to HTTPS for the domains that lack a correct HTTPS vhost, however.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Sep 2015 13:19:38 -0400

Peter Eckersley <[email-masked]> wrote:
    >> So, if the verifier follows an HTTP redirect to an HTTPS site (does it
    >> even have to be same name?), which has a (at that point) bogus
    >> certificate, and Boulder can cope with that, when why bother having
    >> the SimpleHTTP check method at all?
    >>

    > tenant/hypothetical attacker.

Ah, so the attacker can control the wildcard HTTPS, and therefore get HTTPS
certificates for the vhosts that do not have their own HTTPS vhost.

I got it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [