Re: NTLMSSP and Squid

On Sat, 2003-05-10 at 21:49, Henrik Nordstrom wrote:
> On Saturday 10 May 2003 13.26, Robert Collins wrote:
>
> > The stateful helper logic was only ever a workaround for helpers
> > that *had* to maintain state across requests. We can keep the logic
> > for reuse, but it won't be needed once we switch to passing
> > everything through with no challenge reuses ever, and the negotiate
> > is given to the helper.
>
> Keeping state WILL be required somewhere.
>
> You cannot process an AUTHENTICATE packet without knowing the
> information used when generating the CHALLENGE packet.

Yes - I know that. There is a subtle issue here:
state about the handshake vs state for each helper process.

Due to limitations in the original helpers, they *had* to maintain a TCP
session to the domain controller, and the challenges they issued came
from the that controller - so the specific requests could not follow
this pattern:

negotiate->squid->helper 1
helper1->squid->client
client->squid->helper 2
helper2 ->squid

winbind, and AFAIK Guidos' helper, don't suffer from this issue.

> > Yes - we store that in the ntlm request auth structure that we
> > associate with the TCP connection. (We do that today). We then send
> > that back to the helper along with the response.
>
> And I strongly maintain this should not be of a concern to Squid.
> Squid should not even attempt to decode or understand NTLMSSP
> packets. All Squid should worry about is the connections to the
> client and helper.

We *have* to know the handshake logic. Decoding the packets is
orthogonal. (I wasn't suggesting decoding). Simply storing the base64
encoded challenge as we do today will do. And that *will* be needed to
do efficient overlapping stateful requests anyway.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.