Re: Squid-2.5.STABLE?

Henrik Nordstrom wrote:
>
> 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).

Yes, this looks good. For the record, the proposal isn't for another
daemon, but for Samba to provide a squid compatible helper, which speaks
squid's protocol on stdin/out, and Samba's over the pipe.

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

I have to agree (despite having argued the opposite in the past). We
need this NTLMSSP code in one place, and I don't think putting it in
Squid will be nearly as useful for other projects doing NTLMSSP.
Furthermore, while I don't foresee changes to the winbind pipe in 2.2,
it is an internal Samba interface, and *will* change regularly...

Anyway, now all I have to do is find time to put make up the Samba side
of this...

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet@samba.org
Student Network Administrator, Hawker College   abartlet@hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net