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
