Hi Jacob, On Wed, Oct 02, 2019 at 10:52:55AM -0700, Jacob Hoffman-Andrews wrote: > On 9/30/19 6:07 PM, Benjamin Kaduk via Datatracker wrote: > > 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. > 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/. > > 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.
Thanks for setting me straight. > 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. That seems worthwhile. Thanks, Ben _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
