1. 13
  1. 3

    That vulnerability is pretty interesting. I really went down the rabbit hole reading about it.

    Going down that rabbit hole, I read that HTTP validation can only be initiated over port 80. This seemed weird to me, but I eventually found documentation explaining the motivation (see section 8.3).

    Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

    I believe this is a reference to Apache virtual host config, which makes the first defined virtual host the default for unknown domains. However, that affects virtual hosts for HTTP (using the Host header), and HTTPS (using SNI). So I don’t quite understand.

    Perhaps the assumption is that on a shared server, every tenant will have a corresponding HTTP virtual host, but HTTPS is optional? That is, the tenant declared first in the Apache config could impersonate any other tenant that doesn’t have HTTPS, because they will receive other tenants’ connections on port 443. But they’ll never be able to receive them on port 80 because all tenants are assumed to have HTTP.

    HTTPS support is often a paid upgrade feature on shared hosting, so I can see that happening.

    It seems like there’s still a vulnerability here, if the DNS record is created before the virtual host entry for a new tenant, the default tenant could issue a valid certificate for the new tenant within that window. But that’s a race condition with a limited window of opportunity, so I guess it’s more acceptable. And it’s mitigated by the 90 day certificate lifespan.