On 28/12/2015 11:13 a.m., Jason Haar wrote: > Hi there > > I use TOR a bit for testing our WAFs and found that it no longer worked > on my test network that has squid configured in TLS intercept mode. I > currently have squid configured to "splice only" (with peek to get the > SNI name) - ie no bumping - purely so that the squid access_log file > contains better records on HTTPS hostnames But logging is not the only thing that SNI is used for. Both the peek to get the SNI and the resulting IP->hostame changes from finding SNI introduce different logic behaviour. > > 2015/12/28 09:22:04.189 kid1| SECURITY ALERT: Host header forgery > detected on local=194.109.206.212:443 remote=192.168.0.21:40427 FD 30 > flags=33 (local IP does not match any domain IP) > 2015/12/28 09:22:04.189 kid1| SECURITY ALERT: By user agent: > 2015/12/28 09:22:04.189 kid1| SECURITY ALERT: on URL: www.z2b4e372r4.com:443 > > Removing the redirect of tcp/443 totally fixes the problem. What redirect ? > > Anyway, it would appear that squid-3.5.10 in splice-only mode still > enables the "Host header forgery" check? 1) Host check is initiated for all requests received on intercepted traffic. 2) SSL-bump traffic fakes a CONNECT with raw-IP details that gets passed through those (1) checks. 3) SNI presence changes the CONNECT from raw-IP to one with a Hostname. That Hostname needs to match the TCP connection raw-IP. > Surely if all you are doing is > splice-only, it shouldn't be doing that check at all? ie I could > understand triggering blocking actions if squid was part of the > transaction in bump-mode - but when it's "only looking", it is exactly > the same as not doing splice at all - so why trigger the Host header check? It is not only looking. It is updating internal state and logics based on what it sees in the TLS. > > It does look like TOR has something equivalent to a /etc/host file with > fake DNS names - so it's quite understandable that freaks squid out. > Actually, if squid cannot resolve a SNI hostname, shouldn't that skip > the Host name check? 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. > > Also, this isn't that easy to test: it would appear that once I turned > off intercept and successfully used TOR, it must have cached a bunch of > things because I then re-enabled intercept and it's no longer making any > tcp/443 connections - it goes straight out on other "native" TOR ports. > So it may be this can only be tested on a fresh install (or after some > cache timeout period) > 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. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
