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.

And how exactly would you achieve that? If you're a proxy and the
server is far, far away, how do you plan on validating the NTLM hash?

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

Which, generally speaking, you don't have. I wouldn't even bother
working on the issue.

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

That would be true if you transparently transformed a more-secure
auth-scheme to a less-secure auth-scheme (such as NTLM-to-basic or
digets-to-basic [client side first]).
But since you really can't do that but only the other way around,
it's not really an issue, is it?

-- 
	/kinkie