In working to implemented LetsEncrypt at Bitly, I uncovered an issue with the tls-sni-01 validation that limits its trustworthiness in validation.
Issue: The tls-sni-01 validation is intended to prove control over a domain name. The challenge relies on presenting a "<Zi[0:32]>.<Zi[32:64]>.acme.invalid" as the ServerName in the clientHello, and relying on a self-signed certificate to used to complete the TLS handshake that has a single matching subjectAlternativeName/DNSName. Because the server initiating the validation request is presenting the full ServerName expected back, it is thus untrusted and can not be used to imply any relation to the party requesting validation. It is possible to configure a server that generates certificates on-the-fly to match the ServerName presented, and thus passing ALL tls-sni-01 validation attempts. An example of such a server is https://gist.github.com/jehiah/a5b508b8f4efad08e67a Suggestions: 1) Change the requirement that the self signed cert have one DNSName, and require the response to have TWO DNS names. One that matches the requested hostname, and a second that is secret which proves it can only be created by the appropriate party initiating validation 2) Remove reliance on SNI matching, and make the challenge `tls-01` and fulfill the same HTTP response requirements as `http-01` where the Hostname, and request path are untrusted, but the response body with full keyAuthorization proves the connection to the requestor. This opens up the possibility of TLS validation against the $domain being validated instead of relying on a .acme.invalid hostname. Other Notes: There appear to have been discussions about `n` versions of certificates being generated and requiring validation to check a subset of them. I think this vulnerability means `n` is moot as no number of checks for certificates that match the server hello prove control over a domain name. Thoughts? p.s. Thank you to Richard Barnes from Mozilla for pointing me to this mailing list. -- Jehiah http://jehiah.cz/ _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
