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

[Amos Jeffries]

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