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

[Jason Haar]

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

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.

Anyway, it would appear that squid-3.5.10 in splice-only mode still
enables the "Host header forgery" check? 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 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?

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)

-- 
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