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