On Sat, Jan 09, 2016 at 12:56:49AM +0100, Peter Wu wrote: > On Fri, Jan 08, 2016 at 10:23:25AM -0800, Peter Eckersley wrote: > > 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! > > I'll give it a go. Currently thinking of a scanning sites 1k-2k from the > Alexa list, testing port 80 (host: domain, host: ip, host: > surelyinvalid.example.com and no host header), port 443 (no SNI, and SNI > with + Host header like used for port 80). Then I'll try to store a pcap > so all responses can fully be analyzed. > > Are there other things that should be checked as well?
Sites in the top 2K almost all have significant engineering resources available. I'd recommend checking things down around the 100K mark as well, you'll get more representative diversity there. -- 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
