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

["Gerd v. Egidy" <[e-mail]>]

Hi,

I've seen the proposal of Jonathan Rudenberg in [1] to use ALPN to fix the
recently discovered problems with the TLS-SNI challenge [2].

While I think the usage of ALPN will fix the problem at hand, requiring 
support for ALPN on the frontend web servers, accelerators and so on at big 
webhosters will put a burden on the developers and maintainers of these 
systems because ALPN is relatively new and the deployed software and libraries 
will not make it easy to use it for anything but HTTP/2. The same goes for 
developers of ACME clients.

This may hinder adoption or may lead to incorrect or insecure implementations.
As these insecure implementations have thwarted TLS-SNI-01/02, I think we
should be especially sensitive about risks coming from this side.

So I'd now like to revisit the discussion about using HTTP-01 over HTTPS in 
[3] as alternative to TLS-SNI or as complement to TLS-SNI-ALPN.

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.

Let's consider the shared hosting attack with this method:
1. The domains a.example.com and b.example.com are both hosted on the
   same shared hosting server
2. The shared hosting environment doesn't do any checking of the certificates
   their users install onto the shared webserver
3. While allowing the wrong certificate to be presented for a request, the 
   shared hosting server still checks the HTTP Host-header and responds with 
   data from the document root folder of the correct domain
4. The owner of b.example.com activates a certificate with the SAN 
   a.example.com on the shared hosting server
5. He requests the CA to issue the https-01 challenge request
6. The CA is presented the certificate installed by b, but the document root
   of a.example.com does not contain the correct keyAuthorization, so the 
   challenge fails

The attack on TLS-SNI is possible, because the certificate contains everything 
needed to fulfil the challenge. https-01 has the additional check of the
correct keyAuthorization in /.well-known/acme-challenge/{token}.

Advantages of this method:

- Implementing this scheme should not pose undue difficulties on client
developers.

- This protocol should also be easy to include in running infrastructure 
without disturbing regular requests while executing the challenge. As it sends 
the requested hostname via SNI, it works with shared hosting infrastructure.

- As TLS-SNI-01/02 before, it is done completely via HTTPS on TCP port 443. So 
if HTTPS is the protocol you want to use the cert for, you wouldn't need  
access to an additional TCP port like HTTP-01 does. This may not be important 
for regular webhosting, but for a scenario where the certificate protects some 
software running on a host behind a router or firewall only allowing port 443 
through.

What do you think?

Kind regards,

Gerd

PS: Funny thing is, in the course of that previous discussion, Ilari Liusvaara 
already predicted exactly the vulnerability that now has hit TLS-SNI-01/02 
[4].

[1] https://mailarchive.ietf.org/arch/msg/acme/mrKOeRK1K6H_42Hxbt3A1XtLFJM
[2] https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188/2
[3] https://mailarchive.ietf.org/arch/msg/acme/mKKWN44SO1yepCffKpiIMb5bqEs
[4] https://mailarchive.ietf.org/arch/msg/acme/mSp709jDGw2bAEUI1Dq8E4iYpmw