Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ilari Liusvaara <[e-mail]>]

On Wed, Apr 24, 2019 at 12:33:50PM -0400, Ryan Sleevi wrote:
> On Wed, Apr 24, 2019 at 10:23 AM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > I am not sure ALPN extension prevents exploitation.
> >
> >
> > Consider TLS SNI NAT (yes, such things exist) with:
> >
> > - Connections without SNI are handled in some safe way.
> > - Loose registration practices (which made TLS-SNI-01/02 insecure)
> > - No TLS termination (or customer can disable termination for their
> >   name).
> > - No support for TLS-ALPN.
> >
> >
> > Now, attacker claims the RDNS name of the IP address of the host
> > and sets up TLS-ALPN responder (this fails with DNS-type names).
> >
> >
> > Then attacker requests certificate for the IP address. The NAT then
> > sees the SNI, ignores ALPN and sends the connection to the attacker,
> > which can then respond with validation certificate. The authorization
> > passes and CA issues fradulent certificate.
> >
> >
> > The attack exploits the different SNI in requests client would send
> > and what validation uses (TLS-ALPN with DNS names uses the same name,
> > so the attack will not work). The attack against TLS-SNI also exploited
> > this difference (but could work even if TLS termination could not be
> > disabled).
> >
> 
> Just to make sure - these are TLS SNI NAT based on inspecting the TLS
> handshake, without actually terminating it, right? That is, it's doing the
> "middlebox" thing that introduced huge amounts of complexity to deploying
> TLS 1.3, and we're wanting to make sure the IP validation similarly works
> around it.

These things are pretty transparent when it comes to TLS. They do not
need to inspect ServerHello, so they won't. They will not need to
understand most TLS extensions, so they won't. 0-RTT might break if
not taken into account.


However, this sort of thing could be much bigger headache with QUIC...


> The further assumption here is that these products are 'safe by default'
> when omitting SNI, but are otherwise ignorant of ALPN and its semantics.

Well, these need to do something sane when SNI omitted (which might be
just giving an error or sending the connection to some appropriate
default handler).

And whereever that goes is where the raw IP would go.


> If that's roughly correct, would you agree a possible mitigation
> (notwithstanding complexity concerns) 'could' be the use of a client hello
> extension, echo'd by the server (thus confirming it understands the
> protocol, and is not merely 'dumb' parsing but an active participant in the
> TLS handshake), that indicates the IP being verified?

The server must already acknowledge the IP address being verified.

And that mitigation does not work. If the NAT does not know about
TLS-ALPN, it will not know about whatever extension that would be,
and thus just copy it through straight to attacker, who can then
freely reply.



-Ilari