[squid-users] SOLVED - SECURITY ALERT: Host header forgery detected

[Alex Rousskov]

On 7/17/19 10:20 AM, Stephen Borrill wrote:

> A common problem is with sites that have very short TTLs.
> 
> For instance login.live.com sometimes has a TTL of 60 seconds. The squid
> server is using BIND as a recursive DNS resolver and clients are using
> the same BIND instance too. All clients (iOS, Windows, Android)
> sometimes use an old IP address and so you hit the Host header forgery
> detected problem.
> 
> I can't see how to mitigate this problem.

This problem can be mitigated by focusing not on stopping malicious
actors but on minimizing their negative effects. The following two steps
could help AFAICT:

1. When a host header forgery is suspected, allow the transaction
through but under a quarantine regime -- the transaction cannot write to
any cache and cannot read any non-public info. Squid could still warn
about its suspicions, and the admin can be given control over the
frequency of these warnings. Perhaps these warnings can be made
more/less prominent depending on the lack/presence of the confirmation
in #2 below.

2. If (and only if) Squid can validate the server as matching the
client-specified domain name (via the server certificate validation),
the quarantine regime in #1 can be lifted. This is similar to the
validation a client would have to do, of course. However, the client has
more info so sometimes Squid validation will work, and sometimes it will
fail.


Squid already implements portions of #1. No #2 aspects are supported IIRC.


Or we can just change Squid to give the admin control over the frequency
of these warnings but always muddle through with forwarding the
transaction despite known grave risks. We all know that, given a chance,
the vast majority of admins will simply disable warnings.

Alex.


>> -----Original Message----- 
>> From: squid-users <[hidden email]> On Behalf Of Amos Jeffries 
>> Sent: Tuesday, May 15, 2018 21:28 
>> To: [hidden email] 
>> Subject: Re: [squid-users] SOLVED - SECURITY ALERT: Host header forgery detected 

>> The "problem" that needs to be resolved is simply that the genuine 
>> servers do not have a reliable match between their IP and client 
>> presented domain name(s). 
>>
>> Amos