Re: Squid-2.5.STABLE?

Chemolli Francesco (USI) wrote:

> > Chemolli Francesco (USI) wrote:
> > > > You can't blaim the helpers for Squid not telling the helpers
> > > > what the client
> > > > is willing to negotiate.
> > >
> > > Squid _does_ tell the helpers what the client is willing to
> > > negotiate. It's all in the NTLMSSP packet (the amorphous blob
> > > squid sends to the helpers)
> >
> > Err... the negotiation is taking place during the "hello"
> > packet exchange,
> > where the protocol helper protocol only sends "TT\n". Due to
> > this the only
> > negotiation that can take place is that the Squid helper
> > tells the client
> > "irregardless of what you just said, I want this", and then
> > the client can
> > try to adjust to it.. Not much of a window for negotiation, is it?
>
> Doh, you're right.
> Bringing back to the ML, it might interest others.
>
> The problem is not in the TT, but in the fact that
> the "YR" packet doesn't send to the helper the original
> negotiate request.

The problem with the negotiation in the current helper protocol is in my
opinion defenitely TT packet.

The challenge packet sent in response to TT should be based on the
capabilities sent by the client in the hello packet combined with the
capabilities of the server. This is required to at all be able to process
NTLMv2 etc in the helpers. Also needed to select the proper charsets to use
etc.

To make Squids life easier, the helper response to the response packet should
include decoded user credentials, eleminating the need of at all parsing the
NTLM packets within Squid.

I would propose the following very simple protocol:

Squid->Helper:
<sessionnumber> NTLMSSP=<base64blob>

Helper->Squid:

Authentication successful
<sessionnumber> OK user=<loginname, URL escaped>\n

Authentication unsuccessful
<sessionnumber> ERR [user=<loginname, URL escaped>] reason=<why>\n

Further negotiation needed
<sessionnumber> NTLMSSP <base64blob> [user=<loginname, URL escaped>]\n

The sessionnumber is an arbitrary integer 1 -> N, where N is the number of
concurrent sessions supported by the helper (always 1 if the helper cannot
support concurrent sessions)

This would allow for NTLMSSP to be 100% cleanly separated from the Squid core,
giving full freedom in NTLMSSP implementation and verification, and for full
speen NTLMSSP verifications with only a single helper if you like. Also
allows for an easy path to where winbindd provides a NTLMSSP interface
(either directly, or indirectly via another daemon).

Another alternative is to move the whole NTLM and NTLMv2 code into the Squid
core, only having a interface for verifying the challenge+responses directly
to winbindd without any helper at all. If a helper is used in this mode then
it should be totally ignorant to what NTLMSSP is, and only deal with
verifying if a given challenge+response is correct. But this pretty much
totally blocks the door of using other NTLMSSP sources and is not a path I
would like to take.

Regards
Henrik
Received on Fri Sep 06 2002 - 12:21:45 MDT