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

[Ilari Liusvaara <[e-mail]>]

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