Chemolli Francesco (USI) wrote:
> > Senario:
> >
> > Two users behind a second-level proxy not knowing about NTLM
> >
> > User a logs in to a origin server using NTLM, causing the top level
> > proxy's connection to the NTLM enabled server to be logged in.
> >
> > User b requests an object on the same server, and persistent
> > connection
> > management causes user b's request to be sent on the connection opened
> > and by user a, thereby inheriting the privilegies of user a.
>
> Of course this can't be allowed. This is what pinning is all about,
> isn't it?
And I am showing why pinning won't help you unless you know for sure
what the proxy hierarchy looks like.
> Let's rework the scenario.
>
> 2 users ("a" and "b"), both behind two proxies ("1" and "2" with
> "1" being closest to the users).
>
> -first scenario: both 1 and 2 understand NTLM.
Fine, no problem then.
> -second scenario: 2 doesn't understand NTLM
> here matters become nondeterministic, since it all depends on
> if and when 2 will terminate the TCP connection to the server.
> But in this case the existence of 1 won't matter at all: we'd be
> screwed anyways.
Actually the same problems we already have. Having a hierarchy only
makes them less deterministic.
-third scenario: 2 understands NTLM but 1 doesnt
I.e. the proxy the user connects to does not understand NTLM, but the
proxy connecting to the origin server does.
Hmm.. should only be a problem if there is problems in scenario 2. Only
difference is that the problems with connection termination is moved
from proxy 2 to proxy 1.
Problem is still valid if there is other proxies maintaining persistent
connections in the path. Only way I see to guarantee that an NTLM
connection is user specific in a proxy is to not proxy NTLM, all other
approaches is at risk. Eving attempting to proxy NTLM using current
Squid puts you at risk I think.
-- HenrikReceived on Fri Apr 13 2001 - 04:33:32 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:45 MST