On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote: > Hi TLS, > > Like a lot of people here, I'm very interested in ways to reduce the > leakage of users' destinations in the ClientHello's cleartext SNI. It > seems like the past and current proposals to fix the leak are pretty > difficult, involving a lot of careful cryptography and changes to clients > and servers. > > While we're trying to figure that out, I think there's a simple trick that > could help a lot: just let domain owners tell users an alternate SNI in a > DNS entry.
Stumbled upon the following potential problem: Suppose a server has certificate that is wider than what it needs (wildcards anyone?) and it thinks SNI values are more trustworthy than :authority/host (which this document seems to imply), then: DNS spoof can point the A/AAAA records of some name certificate is valid for to that server and set SNI records to some name that this server accepts. Then visitor can open connection (since SNI check and certificate check passes). And then server can respond to queries for unknown vhost in rather dangerous ways. E.g. Suppose victim.example.org has wildcard cert. victim.example.org IN AAAA 2001:db8:1234:5678::ABCD Attacker spoofs: dangerous.example.org IN AAAA 2001:db8:1234:5678::ABCD _443._tcp.dangerous.example.org IN SNI victim.example.org Now if someone visits https://dangerous.example.org/, victim.example.org will see SNI for itself, so it accepts the connection. The client sees the *.example.org name, so it doesn't complain and sends the request automatically. And then the first request will be for https://dangerous.example.org/. Which can trigger unexpected behaviour, potentially exploitable (the web security model is real fragile). -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
