Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Yes.  That can happen.

I forget the name of it, but there was a historic web hosting framework that, in order to improve IP address costs AND maximize compatibility for those upgrading to TLS (non-SNI etc), encouraged the ultimate configuration:

For a given IP address, a large number N of non-TLS port 80 customers, with web hosting contexts discriminated by HTTP/1.1 Host: header are bound to this IP address.

For same said given IP address, one and only one TLS customer is assigned.  This customer’s web context is bound to that IP address and port 80 for the customer’s named Host: values only.  But on the port 443, the IP address is bound to this customer in all cases, regardless of TLS SNI value or lack thereof, all connections to that IP and host will go to the one TLS customer’s web hosting context.

The end result is that https://non-tls-customer.on-same-ip.com will go to the TLS website of the one paying TLS customer on that host IP.

(Normally, of course, there would be a name mismatch and the certificate would not validate.)  In many of these infrastructures, the site admin of the TLS customer would be able to change out that SSL certificate at will.

> On Jan 12, 2018, at 11:39 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
> On Fri, Jan 12, 2018 at 06:21:00PM +0100, Gerd v. Egidy wrote:
>>>> I think you also need:
>>>> 
>>>> - A user is able to trick the server into serving his document root as
>>>> default vhost
>>>> 
>>>> - The webserver serves the default tls vhost, even if the CA requested a
>>>> specific vhost via SNI
>>> 
>>> Well, I think both are impiled by default vhost.
>> 
>> The first yes.
>> 
>> But the second I'm not so sure.
>> 
>> AFAIK, with Apache httpd you'll get the tls default vhost just for requests 
>> without SNI.
>> 
>> Of course not everyone is using Apache, but I think it makes it an additional 
>> condition for the attack to work.
> 
> Actually, reading the detectify post, it seems that at least one hoster
> has the following problem:
> 
> If the legit holder of domain has HTTP but not HTTPS enabled, one can
> take over the HTTPS version, including serving one's own content on it.
> And thanks to HSTS, this can then used to take over the HTTP version
> too.
> 
> 
> -Ilari
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme