RE: NTLM question

> > Or, squid could act as a NTLM client, performing a ntlm-to-basic
> > translation... there is a smallish python proxy doing that.
>
> Interesting idea. But you would first have to implement some form of
> connection pinning I guess..

yes-and-no. It doesn't really require a pinning, it
could be done changing the upstream connection selection mechanism.
We'd need a way to associate an username + password
to an upstream connection, and when selecting the upstream
link we'd need to extra-check that the username+pass that the
downstream client matches the upstream one. If not, initiate a
new connection (notice, it MIGHT already be done, I don't know the selection
algo).

From a protocol point of view, it should work like this (U=upstream server,
C=client, S=squid)

C->S: GET
S->U: GET
U->S: 407 + WWW-Authenticate: NTLM
S->C: 407 + WWW-Authenticate: NTLM + WWW-Authenticate: Basic
C->S: GET + WWW-Authorization: Basic
S->U: GET + WWW-Authorization: NTLM stuff
U->S: 407 + WWW-Authenticate: NTLM stuff
S->U: GET + WWW-Authorization: NTLM stuff
U->S: 200
At this point squid should mark the connection and try to use it as much as
possible.

The only "critical" moment is from when we get the credentials from the user
to when we have the OK.

> > > We have two options for webserver NTLM auth:
> > >
> > > a) Connection pinning
> > >
> > > b) Filter out the NTLM scheme before replying to client
> > >
> > > I think one of the two should be implemented.
> >
> > Both could be actually. Suggested algo:
>
> What I meant was at LEAST one of them SHOULD be implemented.
> If both are,
> fine. If none are, bad things may happen and many users gets
> confused...

IE's error page is verbose but misleading.
For now we could try and detect that there only is NTLM auth and
reply with an error page of our own...

-- 
	/kinkie