On Wed, 23 Sep 2015 18:19:19 -0700 Richard Barnes <[email protected]> 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
