On 07/07/2016 01:53 PM, Amos Jeffries wrote: > 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. Whew! > 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. Sounds good. > Also if the most preferred route is > down the alternatives can happen. That silent and poorly (or un)documented violation of the "client_dst_passthru on" setting feels like a Squid bug to me, but this is not my area of expertise. >> 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. I like that suggestion! However, if we do honor "client_dst_passthru on" for bumped traffic already, then this [far from trivial] "TCP CONNECT" implementation can wait. Thank you, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
