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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
