On Fri, Jul 05, 2019 at 03:02:09AM +0000, Corey Bonnell wrote: > Quite some time has elapsed since the last message of this discussion > was sent, and I don’t think there was any resolution to the concerns > raised. If I’m understanding Ilari correctly, there are networking > appliances (such as HAProxy, as described here: > https://stuff-things.net/2016/11/30/haproxy-sni/) that sniff the > SNI value in the ClientHello to determine the destination TLS server > but do not otherwise decrypt/re-encrypt the flow. If a hosting > provider uses a frontend such as HAProxy, an attacker could register > the .arpa hostname and configure a TLS server to respond to the ALPN > challenge request.
Yes, I meant scenario like that. > I don’t quite understand the need for embedding the IP address being > validated in the TLS ClientHello, as that information is already > available in the destination IP address field of the IP header. If > any packets of the challenge request are NATted before being received > at the final TLS server, then implementations can transmit the IP > address being validated in some implementation-specific manner that > need not be explicitly defined in the specification. Nonetheless, if > the IP address is deemed necessary to include in the ClientHello, it > would probably be best to include it in a new TLS extension. One could also have static reverse mapping to undo the NAT, if every address forwards to different IP/port. And yeah, I can not see the utility of the IP address either. If the packets could be redirected, it seems like that the attacker would be in position to do MITM anyway (which would be even more devastating than anything redirection could do). -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
