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

[Ilari Liusvaara <[e-mail]>]

On Wed, Apr 17, 2019 at 01:54:51AM +0000, Corey Bonnell wrote:
> Hello,
> 
> Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge,
> an SNI value with the in-addr/ipv6.arpa domain name corresponding to
> the iPAddress being validated MUST be specified. I have a concern
> that this requirement suffers the same problem that rendered
> tls-sni-01 insecure: namely, an arbitrary user on a shared hosting
> provider could upload an arbitrary certificate for the required
> .ip-addr/ipv6.arpa domain, thus circumventing any security provided
> by the mandatory SNI extension.
> 
> The mandatory ALPN extension prevents this from being exploited to
> obtain fraudulent certificates, but given how trivially the SNI
> requirement can be defeated in the same manner as for tls-sni-01, I
> don’t believe that requiring SNI provides any security value and is
> not necessary.

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



-Ilari