On 8/07/2016 4:50 a.m., Alex Rousskov wrote: > On 07/07/2016 06:23 AM, Amos Jeffries wrote: >> On 7/07/2016 11:30 p.m., Marcus Kool wrote: >>>>> On 07/06/2016 10:07 PM, Alex Rousskov wrote: >>>>>> Q3. What should Squid do when receiving a wildcard SNI? > >>> Squid _has_ the original IP so why would Squid potentially connect to an >>> other IP ? > >> Because the inbound and outbound connections are not related. > > For intercepted connections they should be IMHO. By default, we should > [if allowed by all the internal checks] connect to the exact IP the > client was connecting to when we intercepted (cache peering, cache hits, > and similar special cases aside, of course). > > Amos, are you sure we not doing that already for intercepted > connections? If we are not, I think this is a missing feature essential > for many (most?) deployments! I certainly understand that some admins > will need to "reroute" some intercepted requests, but rerouting ought to > be an exception, not the norm. Do you agree? Yes we are using the client ORIGINAL_DST as most preferred outgoing route. However, when the admin configures "client_dst_passthru off" to force the DNS results to be used, or configures cache_peer to be used instead we obey those instructions instead. Also if the most preferred route is down the alternatives can happen. > > Please note that going to where the client went does not have to weaken > any internal checks. > > >> The >> outbound is normally done to any of the IPs that the request message >> domain/Host header resolve to. > > For intercepted SSL connections, there is no HTTP request message with > that information so it is especially pressing to connect to where the > client was going. > > Perhaps we screwed it up by replacing the IP address with SNI in the > fake CONNECT target at some point? If that is what changed Squid > behavior, then we should fix the code so that Squid connects to the > intended destination IP regardless of the fake CONNECT target. One way > to do that would be to provide that intended IP address in the fake > CONNECT request itself, via X-Going-To or similar -- doing so would > allow adaptation services to adjust Squid behavior as needed. I think the first CONNECT message which uses raw-IP should end with setting up a (TCP only at this point) server connection of type PINNED. Then the TLS bumping and second CONNECT message with SNI details should use that connection for all the followup activity. That would resolve other problems we are seeing with server connection closure races as well. > > [Wildcard] SNI validation is a separate problem that also needs a > solution. The feature/fix discussed above is not sufficient alone. > Nod. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
