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

[Jacob Hoffman-Andrews <[e-mail]>]

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.

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.