[squid-users] host_verify_strict and wildcard SNI

[Alex Rousskov]

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?

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.

[Wildcard] SNI validation is a separate problem that also needs a
solution. The feature/fix discussed above is not sufficient alone.


Thank you,

Alex.