Couple thoughts Alex, Currently the basic splice rules are being used with regex which means that they can work with wildcard. And I can understand the argument of a client wanting some wildcard domain but I do not know about an application that actually tries to uses such logic. There are cases which the RFC do leave the open minds to get wild and I am not saying if these are right or wrong but, they do states it's a hostname and not a certificate common name or some v3 component. Practically some client can try to contact some arbitrary website and there are couple aspects to it. If a user tries to connect to a site using a company proxy, then what companies will want to allow? Would large companies allow such a connection to be spliced, or maybe they will want to inspect this connection deeper? What about ISP's, these mostly care about cache and not about ACL's, while there are many who uses squid for content filtering. >From where anyone understands, a wildcard should never be required to be tested against any DNS server in the current state of the internet since these do have a strict policy to honor only valid hostname characters. Maybe the future will bring the wildcard into the DNS world, should we consider such an option even if the RFC tends to minimize and containerize the options? Thanks, Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Alex Rousskov Sent: Thursday, July 7, 2016 4:07 AM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: host_verify_strict and wildcard SNI 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
