Re: [squid-users] RE: HostHeaderForgery on dual stack ipv4/ipv6 machine and ICAP

On 30/01/2012 6:29 a.m., James R. Leu wrote:
> Hello,
>
> I'm in the process of implementing an ICAP server, but I'm encountering the
> HostHeaderForgery issue quite often when accessing sites that I can reach
> over IPv6. I've read the KB entry about this. It lists
> that co-locating the NAT device and squid on the same machine,
> or enabling EDNS may resolve the issue.
>
> I'm wondering if my issue is specific to dual stack v4/v6
> or to ICAP. Any suggestions for what I can try to
> work around this issue? If this is specific to
> dual stack v4/v6, I'm here to beat my v6 migration
> drum and I'm willing to help out to resolve it.

The only relation with IP version is if you have disbaled DNS lookups of
IPv4 in Squid. That could make Squid fail to identify the IPv4
destination as valid. The latest 3.2 daily snapshot has DNS updates that
work faster and obsolete that option, so should not hit this particular
aspect.

The only relation ICAP/eCAP/url-rewrite/request_header_access adaptation
have is if they alter the URL and/or Host header to something that does
not sync up. Upstream interception proxies might fail the verify and
produce the conflict error after such alterations.

The most common occurance now happening is with websites which force DNS
update changes across the Internet on very short TTL (er "load balance"
via DNS results). Each time the DNS changes IP Squid will have race
between itself and client as to which picks the change up first. DNS
stability takes up to TTL duration to happen. At which point these load
balancers have de-stabilized the network again for a new IP. We have a
patch in testing now, hopefully it will be in mainstream soon.

>
> My test environment:
>
> Linux laptop with dual stack ipv4/ipv6
> - Fedora rawhide squid (squid-3.2.0.14-6.fc17.x86_64)
> - resolve.conf has v4/v6 nameservers listed
> - squid in intercept mode on same machine as web browser and icap server
> - iptables redirect
> iptables -A OUTPUT -p tcp -m owner --uid-owner 23 -m tcp --dport 80 -j ACCEPT
> iptables -A OUTPUT -p tcp -m tcp --dport 80 -j DNAT --to-destination localhost:3128

3128 is a well known port. You should have a separate (secret) port for
NAT so you can still use 3128 for regular proxy traffic. Best pratice is
to use NAT as a last-resort backup behind other things like WPAD.

You are also missing some mangle table rules here which prevent direct
browser->squid contact over the NAT intercept port. It *must* all go via
the NAT intercept mechanisms to such ports for reliability and avoiding
Host verification errors.

Amos
Received on Sun Jan 29 2012 - 23:13:42 MST