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

[Ilari Liusvaara <[e-mail]>]

On Fri, Jan 12, 2018 at 10:46:47AM -0600, Matthew D. Hardeman wrote:
> 
> 
> > On Jan 12, 2018, at 10:42 AM, Ilari Liusvaara <[e-mail]> wrote:
> > 
> > On Fri, Jan 12, 2018 at 05:20:39PM +0100, Gerd v. Egidy wrote:
> > 
> > That is still vulernable to default-vhost issues if:
> > 
> > - The hoster does not explicitly reserve default vhost (I have seen that
> >  kind of behavior with http:// too). 
> > - The hoster lets customers upload arbitrary certificates.
> > 
> > Note that this is strictly stronger condition than the one for TLS-SNI
> > vulernability, which only required capability to upload arbitrary
> > certificates, but not to control default vhost.
> > 
> > (And there are countermeasures that can detect default vhosts).
> 
> This vulnerability would also require that not only a customer can
> upload an arbitrary certificate but that they can cause that hosting
> infrastructure to present said certificate upon matching the SNI
> label being sent in, correct?

My interpretation of the TLS-SNI issues was that it was exactly
that. No default-vhost control needed.

> Generally that would mean that the attacker would have to be the
> party in control of the default vhost correct?

This http validation over https would need default vhost to be in
control of attacker to be vulernable.


The one system I saw that had default vhost for http:// happened
to point it to pretty privileged vhost. It fixed the issue for
http://, but https:// still points to the same vhost. However,
acme-challenge is filtered for both.


Also, regarding testing default vhosts: Some servers respond with
some default certificate if one sends unknown SNI, some just
fail the connection with alert 112.


-Ilari