On 7/07/2016 11:30 p.m., Marcus Kool wrote: > > > On 07/07/2016 07:15 AM, Amos Jeffries wrote: >> On 7/07/2016 1:55 p.m., Marcus Kool wrote: >>> >>> >>> On 07/06/2016 10:07 PM, Alex Rousskov wrote: >>>> 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. >>> >>> [snip] >>> >>>> >>>> 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. >>> >>> Steve said that Squid rejects the connection because of a failed DNS >>> lookup. >>> So what is Squid doing? Is it doing the following ? >>> - connect to the original IP >>> - use the presented SNI to the server >>> - do a DNS lookup and reject >> >> No it is doing Host: header verification on the faked CONNECT request >> which uses the SNI in the Host: header value. This is not strictly >> required for CONNECT messages, but does potentially prevent Squid using >> other IPs than the original one the client was contacting. > > Squid _has_ the original IP so why would Squid potentially connect to an > other IP ? Because the inbound and outbound connections are not related. The outbound is normally done to any of the IPs that the request message domain/Host header resolve to. It takes special circumstances (such as failing the Host verification) to tie them together. > >> If the SNI is a valid domain name (ie resolves in DNS). Then Squid >> should continue on past the check. > > Does Squid do a DNS lookup or only check the value for "valid" characters? DNS lookup. > >>>> 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. >>> >>> It is interesting to know if an ICAP server or URL rewriter is called >>> and with which parameters when the ios app breaks. >>> >>>> 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!). >>> >>> I use url_rewrite_extras with "... sni=\"%ssl::>sni\" ..." >>> so the URL redirector receives both the original IP address and >>> the peeked SNI value to make its decisions. >>> I agree that an ICAP service needs X-SNI or perhaps X-Squid-SNI to >>> also get both the IP address and the SNI value. >> >> That is a problem for the service. Squid can already send anything in: >> <http://www.squid-cache.org/Doc/config/adaptation_meta/>. > > Which problem are you referring to? I mean it as: IF it is a problem, then its a problem for the service side of things since Squid can send the data fine. > >> Maybe you have mistaken it for the inability of most ICAP services to >> send things back to Squid in the same way. > > The ICAP server needs both the IP and the SNI which Squid can be configured > to do. What do you suggest that an ICAP server needs to send back to > Squid? Sorry I misread your earlier post as implying Squid needs to be extended to send those details. > >>>> 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. >>> >>> To support the weirdest apps Squid might have to simply copy all >>> unusual characters to present the same parameter values to the server. >> >> It is being mapped into the HTTP equivalent value. Which are Host: >> header and authority-URI. Only valid FQDN names can make it through the >> mapping. > > Here things get complicated. > It is correct that Squid enforces apps to follow standards or > should Squid try to proxy connections for apps when it can? Squid isn't enforcing standards here. As Steve original messge says it: "generates a "CONNECT *.example.com:443" request based on the peeked SNI" - which is arguably invalid HTTP syntax, but oh well. It then is unable to do a DNS lookup for *.example.com to find out what its IPs are and does the error handling action for a failure to verify on a CONNECT message. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
