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

[Peter Eckersley <[e-mail]>]

On Wed, Sep 23, 2015 at 06:19:19PM -0700, Richard Barnes 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.

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.

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

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.

-- 
Peter Eckersley                            [e-mail]
Chief Computer Scientist          Tel  [phone] x131
Electronic Frontier Foundation    Fax  [phone]