On 07/06/2016 05:01 PM, Marcus Kool wrote: > On 07/06/2016 11:36 AM, Steve Hill wrote: >> I'm using a transparent proxy and SSL-peek and have hit a problem with >> an iOS app which seems to be doing broken things with the SNI. >> >> The app is making an HTTPS connection to a server and presenting an >> SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if >> this behaviour is actually illegal, but it certainly doesn't seem >> to make a lot of sense to me. > An SNI with a wildcard indeed does not make sense. There are three rather different questions to consider here: 1. Is wildcard SNI "legal/valid"? 2. Can wildcard SNI "make sense" in some cases? 3. What should Squid do when receiving a wildcard SNI? Q1. Is wildcard SNI "legal/valid"? I do not know the answer to that question. The "*.example.com" name is certainly legal in many DNS contexts. RFC 6066 requires HostName SNI to be a "fully qualified domain name", but I failed to find a strict-enough RFC definition of an FQDN that would either accept or reject wildcards as FQDNs. I would not be surprised if FQDN syntax is not defined to the level that would allow one to reject wildcards as FQDNs based on syntax alone. Q2. Can wildcard SNI "make sense" in some cases? Yes, of course. The client essentially says "I am trying to connect to _any_ example.com subdomain at this IP:port address. If you have any service like that, please connect me". That would work fine in deployment contexts where several servers with different names provide essentially the same service and the central "routing point" would pick the "best" service to use. I am not saying it is a good idea to use wildcard SNIs, but I can see them "making sense" in some cases. Q3. What should Squid do when receiving a wildcard SNI? The first two questions are not really important and each may not even have a single "correct" answer. I am sure protocol purists can argue about them forever. The last question is important, which brings us to: > Since Squid tries to mimic the behavior of the server and of the client, > it deserves a patch where instead of doing a DNS lookup and then doing a > connect (based on the result of the DNS lookup?), > Squid simply connects to the IP address that the client tries to connect to > and does the TLS handshake with the SNI (that does not make sense). > This way it mimics the client a bit better. I believe that is what Squid does already but please correct me if I am wrong. When forming a fake CONNECT request, Squid uses SNI information because that is what ACLs and adaptation services usually want to see. However, I hope that intercepting Squid always connects to the intended destination of the intercepted connection instead of trusting its own fake CONNECT request. Whether Squid should generate a fake CONNECT with a wildcard host name is an interesting question: 1. A fake CONNECT targeting an wildcard name may break ACL-driven rules and adaptation services (at least). 2. A fake CONNECT targeting an IP address instead of a wildcard name may not give some ACL-driven rules and adaptation services enough information to make the right decision. 3. A premature rejection of a connection with wildcard SNI does not allow the admin to make the bump/splice/terminate decision. #2 is probably the lesser of the three evils, but I wonder whether Squid should also include the invalid host name as an X-SNI or similar HTTP header in that CONNECT request, to give advanced ACLs and adaptation services a better chance to work around known benign issues where the admin knows the wildcard is not malicious (and to kill wildcard transactions the admin knows to be malicious!). A similar question can be asked about SNI names containing unusual characters. At some point, it would be too dangerous to include SNI information in the fake CONNECT request because it will interfere with HTTP rules, but it is not clear where that point is exactly. Cheers, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
