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