Re: [squid-users] Squid in accelerator mode: Authenticate X-Forwarded-For headers

On 15/12/10 22:27, David Gubler wrote:
> Hi Amos, thanks for your response!
>
>> Be careful, very very careful. ESPN is the example of the month for doing
>> this badly. Their site refuses to open for anyone browsing from a host
>> with
>> local proxy installed.
>
> Thanks for the warning. I'll try it with a proxy server before putting
> this into production.
>
>>> I could configure the Squid's IP address on Apache. But this is
>>> undesirable, because Squid is running on EC2, its IP may change, and
>>> further EC2 instances can come and go.
>>
>> The ONLY way to trust its contents is to verify that the listed
>> content is
>> correct, individually IP by IP starting with the machine directly
>> connecting to supply it. If you can't track exactly where the proxy
>> *is* in
>> cyberspace then you cannot trust anything sent. XFF ACL tests will accept
>> any ACL criteria that version of Squid can take.
>
> I do not fully understand what you mean here, but I'll try to answer
> anyway:
> All the reverse proxy servers will be run by us, so I consider them
> trusted. But since Amazon does not provide availability guarantees or
> stable IP addresses and load may change, we might have to add or remove
> instances on the fly. I'd like to have a system that can handle this in
> a robust way (reconfiguring Apache doesn't count as robust, too much
> room for errors).

I was thinking, if the rDNS of the dynamic EC proxies are set correctly
to produce something in your company domain. Your follow_x_forwarded_for
ACL tests could use the srcdomain or srcdom_regex ACL type to authorize
trust without knowing the actual IP assigned.

>
>> Better, Squid can send Basic auth login credentials in the
>> Proxy_Authentication: header. squid-3.2 adds Negotiate auth protocol to
>> this for more secure logins.
>
> Hmm, that sounds like exactly what I was looking for! Why couldn't I
> figure this out by myself...?
>
>> Noting that XFF contains a ', ' delimited list. These rules may not work
>> as intended.
>
> I'm using the
> header_replace X-Forwarded-For
> directive. If I understood it correctly, it should clear any existing
> X-Forwarded-For headers, and Squid has no reason to add more than one IP
> here, so I think it should be fine.

"forwarded_for truncate" replaces the entire header with only the
immediately connected client IP. The docs appear to be wrongly stating
squid uses its own IP, fixing them now.

The IP may still be "unknown", IPv4 or IPv6 clients.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3