On 9/30/19 6:07 PM, Benjamin Kaduk via Datatracker wrote:
Here's the original post for reference: https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/.the provider. When the TLS SNI challenge was designed it was assumed that a user would only be able to respond to TLS traffic via SNI for domain names they controlled (i.e. if User A registered Host A and User B registered Host B with a service provider that User A wouldn't be able to respond to SNI traffic for Host B). This turns out not to be a security property provided by a number of large service providers. [...]Perhaps I'm misremembering, but I don't think this characterizes exactly the situation that led to the TLS SNI challenge being deemed irredeemable: the issues arise when User B *has not yet* registered Host B, and either the registration validation at the provider was lax or User A could connive to get into the default-SNI handler. The *attack* was possible even when User B has registered Host B, because the validation used a subdomain, as we discuss below, but here we are talking about the SNI routing, which needed to be for an unregistered (or not-validly-registered) name.
It actually doesn't matter whether User B has registered Host B, and it has nothing to do with the default-SNI handler. That was a different vulnerability, mainly in the "http-01" nee "simpleHttp" challenge: https://github.com/ietf-wg-acme/acme/pull/7/files.
Also, TLS-SNI-01 validation did not use a subdomain; it used a constructed name ending in ".acme.invalid".
The issue resulted from allowing someone to upload certificates to a hosting provider for "foo.acme.invalid" without validating their control of "foo.acme.invalid"'s DNS. It also happened to be the case that someone could in certain circumstances upload certificates for "real" domains they don't control, like "example.com", but that wasn't relevant for ACME.
Roland, since we've gotten similar feedback twice, it seems worthwhile to update Appendix A to directly link Frans Rosen's excellent blog post, and to specifically call out that this is different than the "default VHost" issue that led ACME to mandate that the "http-01" challenge use HTTP instead of HTTPS.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
