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 protected]> 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 [email protected] > Chief Computer Scientist Tel +1 415 436 9333 x131 > Electronic Frontier Foundation Fax +1 415 436 9993 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
