Re: Question ICAP-client

Hi folks!

Alex Rousskov wrote:
> On Sat, 2007-03-10 at 16:00 +0200, Tsantilas Christos wrote:
>
>
>> I think that client address/port and squid address/port must copied.
>> They can not (and must not) changed by an ICAP server.
>> The same about authentication information because referred to users
>> authenticated on squid and this info must not changed by an ICAP server.
>>
>
> <rant>
> We are looking at this from different angles. You perceive an ICAP
> server as an extension of a client: a client should have no problem with
> any adaptation of its request by such as friendly server.
>
> I am sure we will eventually see compromised or otherwise unfriendly
> ICAP servers that do nasty things. Such servers would love to do nasty
> things "on behalf" of a client, using client identity if possible. Thus,
> I have a problem with blindly copying sensitive client information into
> requests generated (originated from) the ICAP server.
>
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.

> As an ICAP server developer and seller, I know that many proxy
> installations today use 3rd party ICAP servers, and many proxy admins
> have very little knowledge about what that ICAP server is actually
> doing. Add remote updates to ICAP server software, and you have a
> perfect location for a man-in-the-middle attack point.
>
Yes that's right. But, also without transmitting the username in the
RESPMOD request, this is the perfect location for such a attack. I don't
see the username as a piece of sensitive information, since it only
makes sense in the domain of the proxyserver. I understand that the
username shouldn't leave the proxy domain. But to avoid that, you would
have to block the username transmission via REQMOD.

What I want to say is in essence: In my opinion the transmission of the
username in a RESPMOD request doesn't raise the security problems of
ICAP significantly. Also without transferring the username to the ICAP
server at all, a man-in-the-middle attack is absolutely possible (and
supposably not much harder to achieve). I don't see a big advantage of
getting the username in both requests from an attackers point of view.
I know this doesn't sound very positive. But at last you have to trust
the ICAP-server as you have to trust your browser, your OS, your
provider, ..., even your proxy :-).
And altough this sounds a bit idealistic: it's an administrators job to
know what's going on on his systems.

Please tell me, what you think about that.

>> Not coping addresses and auth info, we are breaking the ACL checking in
>> later steps (e.g in FwdState::fwdStart).
>>
>
> >From your point of view, the solution is to copy. From my point of view,
> this breakage is a sign that we should be extra careful with copying
> such information. That is, there may be a _good_ reason why ACLs do not
> "just work" for requests initiated by the ICAP server.
> </rant>
[...]
>
> Stefan, please test and file a bug report if something does not work
> right after this change.
>
When I have the time I will (not until end of march).

best regards and thanks for examining my problem!!

Stefan Bischof
Received on Wed Mar 21 2007 - 11:04:28 MDT