Hi Niklas, Peter and others, (First time poster here, grabbed this mail from the archives. Explanation of the "vulnerability" is first given, followed by a discussion.)
On Fri, Nov 13, 2015 at 04:35:00PM +0100, Niklas Keller wrote: > This is a followup on "ACME vulnerabilities in SimpleHTTP and DVSNI due to > common webservers' default virtual host semantics", since I don't have that > mail in my archive (was not subscribed to the list back then), I can't > respond directly to that thread. (Stupid mailing lists.) With a sane mail client, you can set the In-Reply-To header to the Message-Id which can be found by clicking the "Show header" link in messages at https://mailarchive.ietf.org/arch/search/?email_list=acme For future reference, the thread starts at https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE_LNhnt0d8U (it is worth reading the full thread as it is not that large). > Could someone explain the exact vulnerability? Since those challenge > payloads are bound to a specific domain, I don't see the problem. > Additionally, I don't see why it's a problem with HTTPS, why is it > mitigated by switching to HTTP? HTTP via port 80 has just the same > semantics for default hosts as HTTPS via 443 has. This vulnerability (as I understand) works as follows: 0. example.com and example.net are owned by two different entities, hosted on the same webserver (shared webhosting). 1. example.com happens to be the first site on the vhost with a valid certificate configured. 2. example.net is another customer on the server which has not yet configured HTTPS. Due to a configuration error, requests to a non-existing vhost now end up at the first (default) vhost, namely example.com. 3. Now example.com can obtain a certificate for example.net (which might not be authorized for that). This is "mitigated" by switching to HTTP because webhosting providers presumably make websites available over http while https is an additional feature. Shared webhosters who serve sites over just https *and* happen to have a misconfigured server such that plain http vhosts are handled incorrectly are probably not common. This vulnerability is purely a configuration issue. For example, nginx can be configured with a catch-all SSL vhost: server { listen *:443 ssl default_server; ssl_certificate dummy.crt; ssl_certificate dummy.key; return "No vhost configured"; } Apache HTTPd can also be configured to address the problem: https://httpd.apache.org/docs/2.4/vhosts/examples.html#default 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. 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. -- Kind regards, Peter Wu https://lekensteyn.nl _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
