[squid-users] host_verify_strict and wildcard SNI

[Alex Rousskov]

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.