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

[Andrew Ayer <[e-mail]>]

On Wed, 23 Sep 2015 18:19:19 -0700
Richard Barnes <[e-mail]> wrote:

> 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'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.

> I am OK with dropping the TLS option for "simpleHttp" validations.
> (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