Re: [Acme] Benjamin Kaduk's Yes on draft-ietf-acme-tls-alpn-06: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

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