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