auth_param ntlm keep_alive interaction with new http/1.1 keepalive behaviour

[Stephen Thorne]

G'day,

Today I had a report of a problem seen with a late version of 3.1.6 + http/1.1,
chunked response and keepalive patches. The problem occurs in the following
situation.

Laptop is on domain ONE, user bob.
Proxy is on domain TWO, and accepts user alice.

What happens with an older version of squid (with no auth_param ntlm keep_alive

GET

< 407, NTLM

GET, NTLM hash

< 407, NTLM hash

GET, NTLM hash for ONE/bob

*** < 407 NTLM, Proxy-Connection: Close
*** (connection torn down and re-established at this point)

GET

< 407, NTLM

GET, NTLM hash

< 407, NTLM hash

GET, NTLM hash for TWO/alice

< 200 OK

GET

< 407 NTLM

GET, NTLM hash

< 407 NTLM hash

GET, NTLM hash for ONE/bob

*** < 407 NTLM Proxy-Connection: keep-alive

GET

< 407, NTLM

GET, NTLM hash

< 407, NTLM hash

GET, NTLM hash for TWO/alice

< 200 OK

*** marks the lines that are different between the two exchanges.

The behaviour seen by the user in the latter case above is many authentication
dialogs in firefox(3.6.x), approximately 1 per proxy-connection established.

Setting "auth_param ntlm keep_alive off" causes the user's authentication
dialogs to stop appearing.

Perhaps with 3.1.7 or 3.2 we should consider defaulting to ntlm keep_alive off.

[Amos Jeffries]

Post by Stephen Thorne
G'day,
Today I had a report of a problem seen with a late version of 3.1.6 + http/1.1,
chunked response and keepalive patches. The problem occurs in the following
situation.
Laptop is on domain ONE, user bob.
Proxy is on domain TWO, and accepts user alice.
What happens with an older version of squid (with no auth_param ntlm keep_alive

GET

< 407, NTLM

GET, NTLM hash

< 407, NTLM hash

GET, NTLM hash for ONE/bob

*** < 407 NTLM, Proxy-Connection: Close
*** (connection torn down and re-established at this point)

GET

< 407, NTLM

GET, NTLM hash

< 407, NTLM hash

GET, NTLM hash for TWO/alice

< 200 OK

GET

< 407 NTLM

GET, NTLM hash

< 407 NTLM hash

GET, NTLM hash for ONE/bob

*** < 407 NTLM Proxy-Connection: keep-alive

GET

< 407, NTLM

GET, NTLM hash

< 407, NTLM hash

GET, NTLM hash for TWO/alice

< 200 OK
*** marks the lines that are different between the two exchanges.
The behaviour seen by the user in the latter case above is many authentication
dialogs in firefox(3.6.x), approximately 1 per proxy-connection established.
Setting "auth_param ntlm keep_alive off" causes the user's authentication
dialogs to stop appearing.
Perhaps with 3.1.7 or 3.2 we should consider defaulting to ntlm keep_alive off.

The 'new' behaviour you are seeing as I understand it is correct NTLM
persistent connection behaviour. Although the popup-per-connection is a
bit extreme, its probably caused by race condition in firefox between
parallel connections being rejected vs the new credentials being
confirmed. Please report it to the firefox people as well, they need to
fix that user-annoying behaviour regardless of what we do.

"off" is the only setting for keep_alive of NTLM and Negotiate configs
which has done anything. In both cases it has always acted as a
hack/workaround to force closed the connection immediately after Squid
offers its range of possible auth methods to the browser. "fixing"
interactions between Squid with NTLM and broken servers and clients.


PS. Does this occur with IE? IMO we can take that browser as the
benchmark for NTLM.

Amos

[Stephen Thorne]

Amos,

GET

< 407 NTLM PC:Close
***** (reconnect)

GET NTLM hash

< 407 NTLM hash

GET NTLM authdetails

But the situation I am experiencing is after a rejected authentication attempt.

GET

< 407 NTLM PC:Close
(reconnect)

GET NTLM hash

< 407 NTLM hash

GET NTLM authdetails

< 407 NTLM
****** (reconnect here is required to avoid multiple auth prompts)

GET NTLM hash

< 407 NTLM hash

GET NTLM authdetails

I have had this problem reported with both MSIE and Firefox. Rigerous testing
with tcpdumps has only been performed with firefox.

[Henrik Nordström]

Post by Stephen Thorne
But the situation I am experiencing is after a rejected authentication attempt.

Squid do not consider the two cases much different.

But yes, it's generally a bad idea to keep the connection open when
trying to renegotiate NTLM, much more so than on the initial negotiation
to use NTLM.

fwiw many browsers will give you multiple auth popups even when using
Basic auth. Can easily be triggered if you visit a packe with many
inlined/embedded objects and the page body is cached or do not require
auth but the inlined/embedded objects is not cached and require auth.

Regards
Henrik