Re: [squid-users] Squid 3.1.1 ICAP Issue

Sorry, the link was eaten bei the to-text conversion :-)

The doc ist to be found (as you all for sure know) e.g. here:

http://www.squid-cache.org/Versions/v3/3.1/cfgman/follow_x_forwarded_for.html

Dr. Michael Portz
IT-Service; IT-Entwicklung

NetAachen GmbH
Grüner Weg 100 | 52070 Aachen
Tel: +49 241 91852 28 | Fax: +49 241 91852 99
www.netaachen.de

Geschäftsführer: Dipl.-Ing. Andreas Schneider
Amtsgericht Aachen: HRB 15383

Diese Nachricht (inklusive aller Anhänge) ist vertraulich. Sie ist ausschließlich für den im Adressfeld ausgewiesenen Adressaten bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, so bitten wir um eine kurze Nachricht. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulässig. Da wir nicht die Echtheit oder Vollständigkeit der in dieser Nachricht enthaltenen Informationen garantieren können, schließen wir die rechtliche Verbindlichkeit der vorstehenden Erklärungen und Äußerungen aus.

Am 13.04.2010 um 13:11 schrieb Michael Portz:

> Did you use the
>
> follow_x_forwarded_for
>
> option in your squid.conf? (Doc for example to be found here)
>
> Regards
> Michael
>
> Dr. Michael Portz
> IT-Service; IT-Entwicklung
>
> NetAachen GmbH
> Grüner Weg 100 | 52070 Aachen
> Tel: +49 241 91852 28 | Fax: +49 241 91852 99
> www.netaachen.de
>
> Geschäftsführer: Dipl.-Ing. Andreas Schneider
> Amtsgericht Aachen: HRB 15383
>
> Diese Nachricht (inklusive aller Anhänge) ist vertraulich. Sie ist ausschließlich für den im Adressfeld ausgewiesenen Adressaten bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, so bitten wir um eine kurze Nachricht. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulässig. Da wir nicht die Echtheit oder Vollständigkeit der in dieser Nachricht enthaltenen Informationen garantieren können, schließen wir die rechtliche Verbindlichkeit der vorstehenden Erklärungen und Äußerungen aus.
>
>
>
>
> Am 13.04.2010 um 12:05 schrieb guest01:
>
>> Hi guys,
>>
>> I may have found a bug related to the ICAP capabilities of Squid 3.1.1
>> (on RHEL5.4). We are currently evaluating a squid deployment which is
>> referenced by this url [1].
>>
>> We want to use Squid as Caching/Authentication-Proxy and ICAP Client,
>> which talks to the Webwasher-server (content filtering proxy) via
>> ICAP. Our Squid has following ICAP configuration:
>>
>> #icap
>> icap_enable on
>> icap_send_client_ip on
>> icap_send_client_username on
>> icap_preview_enable on
>> icap_preview_size 30
>> icap_client_username_encode on
>> icap_client_username_header X-Authenticated-User
>> icap_service service_req reqmod_precache bypass=0
>> icap://yyy.yyy.yyy.21:1344/wwreqmod
>> adaptation_access service_req allow all
>> icap_service service_resp respmod_precache bypass=0
>> icap://yyy.yyy.yyy.21:1344/wwrespmod
>> adaptation_access service_resp allow all
>>
>> (Unfortunately, we can only specify one ICAP server per Squid, but
>> that's another issue/limitation)
>> This deployment is supported by McAfee (Webwasher) and there is even
>> an example configuration[2] for squid and documents for configuring
>> the webwasher by McAfee.
>>
>> ICAP reqmod looks good, everything as expected:
>> Host: yyy.yyy.yyy.21:1344
>> Date: Mon, 12 Apr 2010 10:54:27 GMT
>> Proxy-Authorization: NTLM <BASE64 STRING>
>> Encapsulated: req-hdr=0, null-body=184
>> Preview: 0
>> Allow: 204
>> X-Client-IP: bbb.bbb.bbb.71
>> X-Authenticated-User: <BASE64 encoded USERNAME>
>>
>> GET / HTTP/1.1
>> Host: www.playboy.com
>> Accept: text/html, text/plain
>>
>> ICAP/1.0 200 OK
>> Encapsulated: res-hdr=0, res-body=170
>> ISTAG: "001-000-000003"
>> X-Attribute: sx
>> X-ICAP-Profile: PoC_Policy_TEST
>> X-WWBlockResult: 10
>> X-WWRepScore: 11
>>
>> HTTP/1.1 403 Forbidden
>> Content-Length: 1480
>> Content-Type: text/html; charset=ISO-8859-1
>> Pragma: no-cache
>> Proxy-Connection: close
>> X-Error-Name: requestdynablocked
>>
>> In that case we were assigned to PoC_Policy_TEST and the request to
>> www.playboy.com was blocked. (It seems that we are not supposed to see
>> nice girls at work ;-))
>>
>> If we want to serve to a page which is not blocked (e.g. google.com),
>> we get following request:
>> ICAP/1.0 200 OK
>> Encapsulated: res-hdr=0, res-body=166
>> ISTAG: "001-000-000003"
>> X-ICAP-Profile: default
>> X-WWBlockResult: 81
>> X-WWRepScore: 0
>>
>> HTTP/1.1 403 Forbidden
>> Content-Length: 1279
>> Content-Type: text/html; charset=ISO-8859-1
>> Pragma: no-cache
>> Proxy-Connection: close
>> X-Error-Name: authorizedonly
>>
>> And there is the problem. The ICAP respmod (3.1.1) request does NOT
>> contain the X-Client-IP: bbb.bbb.bbb.71 and X-Authenticated-User:
>> <BASE64 encoded USERNAME> values and that's why the webwasher cannot
>> assign the right policy!
>>
>> If we are using squid 3.0, it works. So in my opinion, this sound like
>> a bug. Right? Has anyboy experiences with ICAP or ICAP issues with
>> Squid 3.1.1?
>>
>> Anyway, besides that problem which I solved by using squid 3.0, there
>> are a couple of other limitation which I don't really want to
>> implement, but I don't see any other change, do you? ;-) At least it
>> does not sound very complicated to implement in c++ ...
>> - possibility to specify more than one ICAP server for a Squid
>> configuration (for example with round robin load balancing or any
>> other kind of loadbalancing)
>> - the much bigger issue is, that Squid as ICAP client does NOT send
>> any group information to the ICAP server, only X-Client-IP and
>> X-Authenticated-User values and no X-Authenticated-Groups attribute.
>> Unfortunately, a policy will be assigned by a group membership. That's
>> why the ICAP server needs that information and it is not a good idea
>> to let the ICAP server lookup this user again (huge performance
>> issue).
>>
>> So, this is quite a long mail, I would appreciate any feedback.
>>
>> best regards
>> Peter
>>
>> [1] http://img714.imageshack.us/img714/7457/topology.png
>> [2] http://wiki.squid-cache.org/ConfigExamples/Webwasher (they are
>> using a proxy chain instead of a icap solution)
>
Received on Tue Apr 13 2010 - 11:54:52 MDT