Re: NTLM and proxying

----- Original Message -----
From: "Chemolli Francesco (USI)" <ChemolliF@GruppoCredit.it>
To: "'Robert Collins'" <robert.collins@itdomain.com.au>; "Chemolli
Francesco (USI)" <ChemolliF@GruppoCredit.it>; "'Henrik Nordstrom'"
<hno@hem.passagen.se>
Cc: <squid-dev@squid-cache.org>
Sent: Friday, April 13, 2001 8:42 PM
Subject: 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).

NTLM to NTLM? Do you mean tunnel mode?. NTLM to NTLM needs a
co-operative user directory again!. (Same as digest-basic or
NTLM-basic).

> > > -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.

Sure.

> > > 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):-)

Make proxy 1 use basic auth to 2 to get permission to CONNECT to port 80
:]
That should be easy enough compared to getting the connect functionality
going in the first palce.
Received on Fri Apr 13 2001 - 04:45:32 MDT