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
