On Fri, Jan 12, 2018 at 10:46:47AM -0600, Matthew D. Hardeman wrote: > > > > On Jan 12, 2018, at 10:42 AM, Ilari Liusvaara <[email protected]> > > 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
