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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
