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

[Ryan Sleevi <[e-mail]>]

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).
>

Thanks Ilari!

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.

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

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?