Squid Web Cache wiki

Squid Web Cache documentation

πŸ”— Host header forgery detected

πŸ”— Symptoms

SECURITY ALERT: Host header forgery detected on ... (local IP does not match any domain IP)
SECURITY ALERT: By user agent: ...

πŸ”— Explanation

This is an alert generated as part of a new security feature added in Squid-3.2 to protect the network against hijacking by malicious web scripts.

As outlined in advisory SQUID-2011:1 these scripts are able to bypass browser security measures and spread infections through the network. They do so by forging the Host: headers on HTTP traffic going through an interception proxy.

:information_source: When port 443 is intercepted the client SNI value used in a generated CONNECT request can have this check performed. If that SNI name does not resolve to the destination server IP(s) this message will be output and TLS halted.

To avoid this vulnerability Squid has resolved the domain name the client was supposedly contacting and determined that the IP the HTTP request was going to does not belong to that domain name.

The first line of the three cites:

  1. the local= (packet destination IP) address of the domain the client was connecting to,
  2. the remote= (packet source IP) address of the client making the connection, and the reason for the alert.

In this case it is β€œlocal IP does not match any domain IP”.

With host_verify_strict enabled there are other checks that can alert.

The second and third lines are self explanatory.

πŸ”— Fix

Use the WPAD/PAC protocol to automatically configure the browser agents instead of intercepting traffic


use an Active Directory(R) GPO to automatically configure the browser agents instead of intercepting traffic.


configure the browsers manually

:information_source: all of these methods make the client browser agent aware of the proxy. This causes the browser to send a differently formatted HTTP request which avoids both the security vulnerability and checks which are displaying the alert.

You may also determine from the details mentioned in the alert that the client has being hijacked or infected. In this case the proper fix may involve other actions to remove the infection which we will not cover here.

πŸ”— Workaround

:information_source: As of May 2012, Squid- will pass traffic which fails these validation checks to the same origin as intended by the client. But will disable caching, route error recovery and peer routing in order to do so safely. The intention in future is to support those features safely for this traffic.

There really are no workarounds. Only fixes. Although there may be some things configured in the network which are causing the alert to happen when it should not.

The below details are mandatory configuration for NAT intercept or TPROXY proxies. Some of them appeared previously to be optional due to old Squid bugs which have now been fixed.

These are optional and may not be possible, but is useful when they work:

πŸ”— Alternative Causes

Interception performed at the DNS layer by the use of dnsmasq tool or other DNS trickery altering the IP destination the clients receive for a domain lookup.

In these cases Squid-3.2 hijacking protection will pass the traffic through to the clients destination IP address without redirecting to any specific other IP. Additional Destination-NAT configuration is required to identify the packets and ensure they are delivered to the correct site regardless of any other details.

Categories: KnowledgeBase

Navigation: Site Search, Site Pages, Categories, πŸ”Ό go up