Re: Question ICAP-client

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Wed, 21 Mar 2007 11:41:35 -0600

On Wed, 2007-03-21 at 18:04 +0100, Stefan Bischof wrote:
> I don't see your point (probably I don't understood something). The
> ICAP-server already knows the clients username at this point, because of
> the REQMOD request. If the evil ICAP-server redirects the request to a
> evil HTTP-server, it wouldn't be a problem to send the username to the
> HTTP-server and then back to the ICAP-server via RESPMOD.

This is not about transmitting a username to the ICAP server. It is
about making Squid believe that the request that originated from the
ICAP server is authenticated (with _client_ credentials).

An ICAP server can do pretty much anything. However, whether the ICAP
server can do something _while being authenticated as the client_ is up
to the proxy. The current code grants such authenticated status to
requests generated by the ICAP server.

I agree that a client and an admin already have to trust the proxy. The
question is whether the client is authenticating herself with the proxy
under the assumption that her authenticated requests will not be altered
substantially. For example, there may be a big difference between an
anonymous employee surfing porn and a specific/authenticated employee
surfing porn... The admin may have reasonable trust in Squid or another
well-known proxy, but may not have the same level of trust in some
obscure porn-blocking ICAP server being installed and maintained by a
3rd party.

A complete solution to this problem is probably too big to implement in
the foreseeable future. However, it would be nice to have a special mode
in Squid where ICAP request alternations are not allowed (but request
satisfaction and REQMOD are OK). This should take care of most problems
in this context.

Full support of such a safe no-request-alternation mode is not easy
because many ICAP servers use "ICAP 200 OK" to return unmodified
requests. However, we can limit the check to comparing request headers
and ignoring POST/PUT issues.

Another useful "safe ICAP" mode could prevent any adaptations (but allow
blocking), with a "how to detect a blocking message?" problem.

$0.02,

Alex.
Received on Wed Mar 21 2007 - 11:41:49 MDT

This archive was generated by hypermail pre-2.1.9 : Sun Apr 01 2007 - 12:00:01 MDT