[Acme] Fixing the TLS-SNI challenge type

[Jonathan Rudenberg <[e-mail]>]

As many of you are probably aware, Frans Rosén of Detectify discovered a method of exploiting many shared hosting providers to obtain unauthorized certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt is in the process of removing support for these challenge types[1].

Obviously this is not ideal, as the TLS-SNI challenge is useful in a variety of use cases. The good news is that TLS-SNI-02 appears to be fixable.

In order to get the ball rolling on a fixed version (aka TLS-SNI-03), here’s a straw proposal, based on something originally publicly suggested by Ryan Sleevi[2]:

Start with the TLS-SNI-02 challenge specification, and add the requirement that the ACME server MUST send an ALPN extension in the ClientHello with a single “acme” protocol name, and the ACME server MUST confirm that the ServerHello also includes an ALPN extension with a single “acme” protocol name.

The only concern I’ve seen about this is the theoretical possibility that servers might just repeat back the ALPN extension with the same protocol name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or similar) to see if this behavior exists in the wild.

Jonathan

[0] https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996
[1] https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
[2] https://www.mail-archive.com/[e-mail]/msg08984.html