Re: ntlm authentication concurrency

 On Tue, 13 Dec 2011 15:48:41 +0100, Vincent Miszczak wrote:
> Hello,
>
> My name is Vincent Miszczak and I'm working as a network engineer for
> a company where we use Squid.
> I'm trying to introduce new cool features such as dynamic SSL bump
> and so on before my boss buys a Palo Alto device.
>
> Among those features, there is one missing and I cannot get why :
> ntlm authentication concurrency. You have released a multiplexer for
> old helpers (and I have written a new one with some new features like
> wiping unused helpers,...) and Squid supports the protocol, but
> actually concurrency on 3.1 (we are talking of production suitable
> products) cannot be configured and that's nasty. What's more the
> documentation http://www.squid-cache.org/Doc/config/auth_param/ is
> wrong. "Removed Basic, Digest, NTLM, Negotiate auth_param ...
> concurrency setting option.". There is no such parameter for NTLM as
> far as I know.

 Thanks.

>
> Can I hope to find this feature in a new 3.1 release?

 No. nor in a 3.2 release.

 The reason why it is not supported is that NTLM (and Negotiate to a
 lesser degree) protocol is stateful and spreads pieces of the
 challenge/token-exchange/credentials-response over several HTTP
 requests. To handle this each helper has a 1:1:1 relationship pinning an
 active client and a winbind connection state together through the helper
 state data. From the beginning of the auth handshake through to its
 completion. This stateful relationship effectively "locks" the helper to
 1 concurrency channel.
   The other helpers can support a form of fake-concurrency by buffering
 the input requests and processing them in sequence very fast. To Squid
 this is essentially the same as real concurrency, just slower. But for
 NTLM processing two token-exchanges in a row is not an option, will
 corrupt the credentials validation.

 It is theoretically possible to write an NTLM helper which accepts
 concurrency tags and maintains a bunch of separate states internally
 linking the channel-ID to a particular winbind connection. Getting this
 right is a lot of work for an auth protocol which is already obsolete,
 and still does not avoid the really problematic limit of 256 total
 winbind connections. So we have not made any real effort to add support.
 Concentrating efforts more on promoting the use of Kerberos auth which
 is faster, more secure, and more efficient than NTLM (not to mention
 being the default for all Win XP SP2 and later software from MS).

 Squid needs design adjustments to link a particular channel+helper pair
 to the client connection instead of just the helper. Leaving a helper in
 the available pool until its channels are all in-use. These would be
 useful for adding Kerberos concurrency support in future and would be
 accepted if you want to do it. Unlike NTLM that auth protocol still has
 some years of life ahead.

 Amos
Received on Wed Dec 14 2011 - 01:46:35 MST