Re: [Acme] ACME vulnerabilities in SimpleHTTP due to common webservers' default virtual host semantics

[Peter Wu <[e-mail]>]

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