2016-01-08 19:23 GMT+01:00 Peter Eckersley <[email protected]>: > On Fri, Jan 08, 2016 at 06:27:09PM +0100, Peter Wu wrote: > > > Peter (Eckersley), you reported this concern with the premise that it is > > a common configuration mistake that impacts many hosting providers. Do > > you have scans backing up that concern? Websites that are managed by a > > single entity (i.e. not shared hosting providers) with this > > configuration "mistake' are not a problem. > > I haven't spent the time to conduct a thorough scan to get numbers, but > this type of configuration is very easy and natural to create, and manually > examining the https:// responses of a handful of Alexa top 100K domains > (starting in the middle of the list, not the top) showed a tremendous > diversity of strange behaviours for domains where https:// has not been > officially deployed. > > If someone wants to do a scan to try to characterise all of those > behaviours, go for it! > > > > > > > The restriction in the specification has an unfortunate consequence: > > sites which are only accessible over port 443/HTTPS (because other ports > > are blocked / not forwarded in a NAT network) can no longer be > > validated. > > That's not the case. You can use the TLS-SNI-01 challenge type on those > systems. > > The current language describing it in the spec is terrible and needs to > be rewritten, but it's quite simple: add an extra :443 vhost entry to > your server config, serving a self-signed cert created to pass the > challenge.
Unfortunately, this requires a server configuration reload. http-01 is still a lot easier, it doesn't require any configuration change. I think it's best to allow http-01 over HTTPS on port 443 if port 80 is not reachable. This should eliminate the vulnerability, but allow verifying HTTPS-only sites with http-01. Best Regards, Niklas > -- > 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
