RE: NTLM and proxying

> > > So NTLM proxying ends up in a bad idea unless the whole
> environment
> is
> > > controlled and you know there is no second level proxies
> not knowing
> > > about NTLM.
> >
> > 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.
> > a opens connection and authenticates via NTLM. 1 pins upstream to a
> > (it pins the a-1 fd to the 1-2 fd). 2 does the same, and
> everybody is
> happy.
> > b opens connection and authenticates via NTLM. 1 doesn't
> use the same
> > upstream link, since it's reserved for the a-1 to 1-2 tie)
> and opens a
> > new one. Everybody is happy again
>
> But 1 will have recieved a basic challenge. due to 2 doing
> the bridging.
> Either that or 1 made a tunnel mode to 2.

I had the roles reversed, with 2 not understanding NTLM and 1 yes.
I see your point. The bridging feature SHOULD NOT be enabled
by ISPs doing cache hierarchies.

> If 1 opened a tunnel mode conneciton to 2, 1 is managing the
> issues and
> 2 becomes irrelevant.
> If 1 used basic auth, 2 is managing the issues and 1 become
> irrelevant.
>
> Note: The pinning _must_ be basic-username to NTLM-connection-fd, NOT
> downstream fd to upstream fd. Otherwise downstream proxies confuse
> upstream bridges.

It depends. It must be fd-to-fd in case of NTLM-to-NTLM bridging.
It SHOULD be user-to-fd in case of basic-to-NTLM bridging
(not that it wouldn't work otherwise, it would just be much
less efficient).

> > -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.
>
> To support this case, 1 needs to detect this somehow, and
> request from 2
> via authenticated tunnel mode.

IF 2 supports that. Otherwise, it's just a failure.

> > This all to say: NTLM auth sucks. If 1 supports it or not
> won't change
> > things.
> > Also, we really have no way of knowing what will happen
> > upstream, it doesn't matter if "we" is the client or a proxy.
> > If "we" is the "1" proxy and we don't handle NTLM, we will blunder
> earlier,
> > but we'll still blunder. Yes, NTLM auth sucks. Big time.
> Blame Canada
> [1].
>
> My take on the scenarios:
>
> 2 proxies, 4 clients.
>
> 1, 2 proxy, child, parent
> a,b clients of 1
> c,d clients of 2.
>
> if 2 support NTLM, it gateways to basic. 1 only sees basic
> requests. No
> issue there.
> if 2 doesn't support NTLM, c,d are in trouble... but if 1
> does and can
> make CONNECT requests and then insert the user request into the tunnel
> a,b can work properly.
> if 2 and 1 doen't support NTLM, everything the way it is today.

Most CONNECT security settings would refuse dest ports other than
443. Other than this, it might work (to the dismal of 2's administrator
which wouldn't be able to log accesses):-)
Received on Fri Apr 13 2001 - 04:39:09 MDT