> 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: >> >> The problem mentioned with running HTTP-01 over HTTPS was the default-vhost >> problem. But that could be avoided with checking the SAN like this: >> >> The client creates a self-signed certificate or uses a certificate signed >> by any CA as long as it carries the hostname he wants to challenge within >> the subject alternative names (SAN). >> >> The CA does the regular HTTP-01 request. But this request is via HTTPS >> and the CA sends the hostname via SNI. The CA does not do any validity or >> trust checks on the presented certificate except to check the hostname >> in the subject alternative names for authorization. >> >> I'd call this type of challenge "https-01" to let the client explicitly >> request this type of challenge in contrast to requesting "http-01" over >> http. > > 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? Generally that would mean that the attacker would have to be the party in control of the default vhost correct? _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
