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). -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
