[squid-users] Squid 3.1.1 ICAP Issue

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 - 10:05:31 MDT