Re: NTLM and proxying

From: Robert Collins <robert.collins@dont-contact.us>
Date: Fri, 13 Apr 2001 18:54:45 +1000

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Chemolli Francesco (USI)" <ChemolliF@GruppoCredit.it>
Cc: <squid-dev@squid-cache.org>
Sent: Friday, April 13, 2001 6:37 PM
Subject: Re: NTLM and proxying

> Chemolli Francesco (USI) wrote:
>
> > If the pinning was possible, we could even act as a basic-to-NTLM
> > bridge for such cases (there was a python app announced of
> > freshmeat today that does exactly this). Or maybe we have some
> > ways to do this even now?
>
> The bridge/gateway idea sounds interesting.. would allow non-NTLM
> browsers to be used to connect to NTLM-only services.

Yes. New idea: NTLM to basic or digest. We'd need a co-operative server
such as SAMBA to validate the NTLM username and give us the matching
plaintext though.

> > basic-to-NTLM bridge means:
> >
> > 1) we see a server reply with Authenticate: NTLM scheme and no
> > alternate auth methods offered.
> > 2) we strip that out, and replace that with a Basic challenge
>
> Hmm.. if you have pinning then you could just as well implement NTLM
> proxying. The more interesting approach would then be to add a Basic
> challenge, and optionally (per configuration) filter out NTLM.

We need an association between the two auth types, and in the case of
NTLM bridging (in either direction) a connection pinning & reserving
mechanism.

> Having NTLM proxied outside the LAN is a security risk, as a carefully
> crafted NTLM challenge can reveal much details about the NTLM hash of
> the user, so I imagine some networks would like to have NTLM proxying
> disabled in all cases even if the proxy is capable of handling it.

Yes. This can be implemented via the header filter acl today as long as
we extend it to apply to replies as well as requests.

> Perhaps we should have configuration directive to enable/disable wich
> authentication methods are forwarded to the browsers, and gateways
from
> Basic to NTLM and/or Digest where possible (and enabled).

Config directive for auth methods already exists - header filter.
Gateways is a nice idea - should be any to any (for supported
protocols). Ie basic to any is easy if we have the client side for "any"
available. Digest or NTLM to any requires a co-operative user directory.

> I am a bit reluctant about having auth gatewaying/bridging enabled by
> default. Having Basic->NTLM/Digest gatewaying enabled might put the
> users at risk if they beleive that a "secure" login mechanism is used
> but in fact their login information is sent in plain text between the
> browser and proxy.

Yes. Agreed 100%

> / Henrik
>
>
Received on Fri Apr 13 2001 - 02:55:09 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:45 MST