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

From: "Gerd v. Egidy" <[email-masked]>
Date: Fri, 12 Jan 2018 17:20:39 +0100

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

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Fri, 12 Jan 2018 10:28:31 -0600

> On Jan 12, 2018, at 10:20 AM, Gerd v. Egidy <[email-masked]> wrote:
> 

As I’ve not yet considered the other aspects, I can’t comment as to the advisability.

I did want to say that if an acceptable mechanism is found in this manner, it does help with some but not all in-band TLS validation mechanisms.  It works for web server cases.  It does not fully replace the mechanisms of the TLS-SNI sort because it would not work for other protocols running over TLS (like SMTP/TLS).  The TLS-SNI mechanisms do facilitate that.  Still, if the risks are otherwise acceptable, such a challenge mechanism might be a path of least resistance for those impacted by the TLS-SNI-01 deprecation.

---

From: "Gerd v. Egidy" <[email-masked]>
Date: Fri, 12 Jan 2018 17:33:43 +0100

> I did want to say that if an acceptable mechanism is found in this manner,
> it does help with some but not all in-band TLS validation mechanisms.  It
> works for web server cases.  It does not fully replace the mechanisms of
> the TLS-SNI sort because it would not work for other protocols running over
> TLS (like SMTP/TLS).  The TLS-SNI mechanisms do facilitate that.

Really? Isn't TLS-SNI-01/-02 just allowed over TCP port 443?

"This connection MUST be sent to TCP port 443 on the TLS server"

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Fri, 12 Jan 2018 10:36:06 -0600

Yes.

But there are people forwarding that to the other service port so their application only has one real listener and then that non HTTP TLS server still manages to complete the TLS-SNI challenge (via port 443).

> On Jan 12, 2018, at 10:33 AM, Gerd v. Egidy <[email-masked]> wrote:
>

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Fri, 12 Jan 2018 10:38:58 -0600

Not that I think that’s a sane or normal thing to do.  But apparently it’s a thing people are doing.  I didn’t know about it either until I saw this twitter post and did a little research on it.

https://twitter.com/eey0re/status/951622012211900416

> On Jan 12, 2018, at 10:36 AM, Matthew D. Hardeman <[email-masked]> wrote:
> 
> Yes.
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jan 2018 18:42:33 +0200

> request this type of challenge in contrast to requesting "http-01" over

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jan 2018 18:46:39 +0200

On Fri, Jan 12, 2018 at 10:28:31AM -0600, Matthew D. Hardeman wrote:
> I did want to say that if an acceptable mechanism is found in this
> manner, it does help with some but not all in-band TLS validation
> mechanisms.  It works for web server cases.  It does not fully
> replace the mechanisms of the TLS-SNI sort because it would not work
> for other protocols running over TLS (like SMTP/TLS).  The TLS-SNI
> mechanisms do facilitate that.  Still, if the risks are otherwise
> acceptable, such a challenge mechanism might be a path of least
> resistance for those impacted by the TLS-SNI-01 deprecation.

I had actually written code (but ripped it out after LE announced
they are dropping support for TLS-SNI) that supported TLS-SNI
challenges at TLS level. This code relied on being able to detect
validation attempts at ClientHello time and then handling those
connections specially.

-Ilari

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Fri, 12 Jan 2018 10:46:47 -0600

> On Jan 12, 2018, at 10:42 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

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?

---

From: "Gerd v. Egidy" <[email-masked]>
Date: Fri, 12 Jan 2018 18:03:34 +0100

> - The hoster lets customers upload arbitrary certificates.

I think you also need:

- A user is able to trick the server into serving his document root as default 
vhost

- The webserver serves the default tls vhost, even if the CA requested a 
specific vhost via SNI

> certificates, but not to control default vhost.

Yes, definitively.
 
> (And there are countermeasures that can detect default vhosts).

Could you explain in more detail?

Will they still work in conjunction with TLS and SNI?

Kind regards,

Gerd

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jan 2018 19:04:57 +0200

On Fri, Jan 12, 2018 at 10:46:47AM -0600, Matthew D. Hardeman wrote:
> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jan 2018 19:08:47 +0200

> - The webserver serves the default tls vhost, even if the CA requested a 

Well, I think both are impiled by default vhost.
 
> Will they still work in conjunction with TLS and SNI?

One trick: Use some wild host value, and see that either TLS handshake
fails with alert 112, or that returned certificate is different.

-Ilari

---

From: "Gerd v. Egidy" <[email-masked]>
Date: Fri, 12 Jan 2018 18:21:00 +0100

> > I think you also need:
> > 
> > - A user is able to trick the server into serving his document root as
> > default vhost
> > 

The first yes.

But the second I'm not so sure.

AFAIK, with Apache httpd you'll get the tls default vhost just for requests 
without SNI.

Of course not everyone is using Apache, but I think it makes it an additional 
condition for the attack to work.

> fails with alert 112, or that returned certificate is different.

Did you (or anybody else) see any setup where that check gives the wrong 
results?

Kind regards,

Gerd

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jan 2018 19:39:44 +0200

> condition for the attack to work.

Actually, reading the detectify post, it seems that at least one hoster
has the following problem:

If the legit holder of domain has HTTP but not HTTPS enabled, one can
take over the HTTPS version, including serving one's own content on it.
And thanks to HSTS, this can then used to take over the HTTP version
too.

-Ilari

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Fri, 12 Jan 2018 11:56:31 -0600

Yes.  That can happen.

I forget the name of it, but there was a historic web hosting framework that, in order to improve IP address costs AND maximize compatibility for those upgrading to TLS (non-SNI etc), encouraged the ultimate configuration:

For a given IP address, a large number N of non-TLS port 80 customers, with web hosting contexts discriminated by HTTP/1.1 Host: header are bound to this IP address.

For same said given IP address, one and only one TLS customer is assigned.  This customer’s web context is bound to that IP address and port 80 for the customer’s named Host: values only.  But on the port 443, the IP address is bound to this customer in all cases, regardless of TLS SNI value or lack thereof, all connections to that IP and host will go to the one TLS customer’s web hosting context.

The end result is that https://non-tls-customer.on-same-ip.com will go to the TLS website of the one paying TLS customer on that host IP.

(Normally, of course, there would be a name mismatch and the certificate would not validate.)  In many of these infrastructures, the site admin of the TLS customer would be able to change out that SSL certificate at will.

> On Jan 12, 2018, at 11:39 AM, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 13 Jan 2018 22:05:13 +0200

> condition for the attack to work.

Nginx is popular too, and with Nginx at least, the default catches all
requests that are not for explicitly configured vhost.

This happens independently for both HTTP and HTTPS.

> Did you (or anybody else) see any setup where that check gives the wrong 

I know one setup, where currently that detects one of the explicit
vhosts as default vhost (because it actually is). Changing that if
needed sould not be terribly hard.

-Ilari