[squid-users] Host header forgery affects pure splice environment too?

[Jason Haar]

On 28/12/15 14:34, Amos Jeffries wrote:
> Removing the redirect of tcp/443 totally fixes the problem.
>
> What redirect ?

tcp/443 redirect - sorry bad choice of words (really iptables REDIRECT).
ie TOR starts working if it isn't going through squid (which I
appreciate doesn't add much to this conversation - but it does prove
it's not some generic firewall/network problem)

> Well, Squid should not get to the point of testing Host name in the HTTP
> messages. SNI is mandatory to contain a resolvable FQDN. Not doing so is
> a TLS protocol violation and Squid should just abort down to either
> terminate or blindly tunnel based on your on_unknown_protocol settings.

Ooh - I haven't heard of "on_unknown_protocol"? I don't see it in the
squid.conf.documented that comes with squid-3.5.10?

That sounds exactly what's needed. What we have here is a situation
where a "bogus" application is routing through tcp/443 - which we choose
to do transparent TLS intercept on. What I want is to use peek/splice to
improve our logging - but otherwise not fiddle with any application that
happens to run over tcp/443.

I did find "on_unsupported_protocol"  - so added
"on_unsupported_protocol tunnel SSL_https" (acl SSL_https port 443) -
but that triggered a squid-3.5.10 config error? Is this a new squid-4
feature?


> if you want to dig into this further I suggest getting a
> "debug_options ALL,9" output and looking at what cache.log says about
> the state of the request that is being checked and failing.

I think we know what the problem is: TOR is making TLS connections (I
don't know if they're HTTPS) on port 443 and uses SNI names that aren't
real?


-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1