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