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? On Fri, Jan 08, 2016 at 11:56:39AM -0800, Peter Eckersley wrote: > On Fri, Jan 08, 2016 at 08:42:57PM +0100, Niklas Keller wrote: > > > 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. > > That's pretty corner case-y behaviour for a very specialised use case > (server *must* have port 80 firewalled, and cannot possibly perform a > graceful server reload). Are there other voices in favour of special > casing DV behaviour for that use case? Trying port 443 after port 80 is unreachable is a workaround and probably too specific. If a configuration issue like the default vhost is a concern, then I would like to suggest validating the subject CN or SANs of the returned certificate even if self-signed or expired. (This modification, but also the existing http-01 validation, seems vulnerable to a MitM attack where the attacker controlling the network can cause false validations, but is not the topic of this mail.) In my last mail, I meant to say "not possible with http-01". I am using the simp_le ACME client with Let's Encrypt and encountered this limitation when trying it at home. The following scenarios assume that a webserver is already running a live website. An advantage of the http-01 method over tls-sni-01 is that a webserver can delegate the validation by proxying the request or by pointing to a specific directory on the filesystem. Both approaches work with an unprivileged ACME client. The SNI method requires that an ACME client can modify the webserver configuration (add a new vhost + cert) and reload it. It cannot be delegated via proxying because the server needs to parse the Client Hello first. In short, http-01 operates on a level below TLS and is more flexible than tls-sni-01 and allows delegation of certificate validation. -- Kind regards, Peter Wu https://lekensteyn.nl _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
