850821 - Infinite loop/flood of NTLMSSP_NEGOTIATE requests and 401s after NTLM auth dialog cancel

Status: UNCONFIRMED

(Core :: Networking: HTTP, defect, P5)

Description

[James Baker]

Attachment: log.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.33 (KHTML, like Gecko) Chrome/27.0.1430.3 Safari/537.33

Steps to reproduce:

Install all-default Firefox 19.0.2 on a fresh/clean Mac OS X 10.8.2.
Navigate to web page configured to WWW-Authenticate: NTLM (Apache/2.2.22 mod_auth_sspi/1.0.4).
See the browser auth dialog. (After server sends back HTTP 401 with HTML body)
Click the "cancel" button.


Actual results:

Firefox re-requests the same page with Authorization: Negotiate of type NTLMSSP_NEGOTIATE with flags 0x00088207 and NULL workstation domain/name.
It receives another identical 401 response from the server.
It sends an ACK.

It then repeats that cycle infinitely, rapidly filling up the server logs.


Expected results:

Expected: Firefox should have ceased the NTLM authentication sequence and displayed the HTML body of the 401 response.

Bug 261044 (from 2004) sounds the most similar after reading through all the NTLM bugs I can find.

Relevant lines from the log include:
> Suspending the transaction, asynchronously prompting for credentials
> nsHttpChannelAuthProvider::OnAuthCancelled
> ...
> Resuming the transaction, we got credentials from user

Comment 1

[James Baker]

Attachment: PCAP trace of Firefox behavior

Comment 2

[James Baker]

Attachment: PCAP trace of Chrome behavior

Comment 3

[James Baker]

Actually, let me paste the full 10 lines where the HTTP log shows us going wrong:

nsHttpChannelAuthProvider::PromptForIdentity [this=1185f6360 channel=112a08308]
Suspending the transaction, asynchronously prompting for credentials
nsHttpChannelAuthProvider::OnAuthCancelled [this=1185f6360 channel=112a08308]
nsHttpChannelAuthProvider::GetAuthenticator [this=1185f6360 channel=112a08308]
nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=1185f6360 channel=112a08308 proxyAuth=0 challenges=Negotiate]
nsHttpChannelAuthProvider::GetIdentityFromURI [this=1185f6360 channel=112a08308]
nsHttpAuthCache::GetAuthEntryForDomain [key=http://alpo:-1 realm=]
  identity invalid = 0
nsHttpAuthCache::SetAuthEntry [key=http://alpo:-1 realm= path=/ metadata=0]
Creating nsHttpAuthNode @a676168
nsHttpChannel::OnAuthAvailable [this=112a08000]
Resuming the transaction, we got credentials from user

Looks like the problem is perhaps in-between nsHttpAuthCache and nsHttpChannel, where we go from "identity invalid" to "AuthAvailable".

Comment 4

[Matthias Versen [:Matti]]

Do you know if this worked in previous firefox versions ?

Comment 5

[James Baker]

I do not know, I haven't tried to binary-chop through FF versions to isolate the regression.  I don't even know that it's a regression, really - just presuming that someone would have noticed in the last 10 years otherwise.

Comment 6

[James Baker]

We've discovered that this is only an issue with multiple WWW-Authenticate headers.  Here's what our headers looked like:

HTTP/1.1 401 Authorization Required
Date: Thu, 14 Mar 2013 16:43:17 GMT
Server: Apache/2.2.22 (Win32) mod_auth_sspi/1.0.4
Last-Modified: Tue, 12 Mar 2013 13:39:29 GMT
WWW-Authenticate: NTLM
ETag: "b09-4d7ba6b3582f7"
Accept-Ranges: bytes
Vary: Accept-Encoding
P3P: CP="NON"
X-UA-Compatible: IE=Edge
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Content-Length: 2825
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html
Proxy-Support: Session-Based-Authentication

Note the duplicate "WWW-Authenticate: NTLM" header.  We setup Fiddler to proxy this request and auto respond without the duplicate header:  With a single NTLM header FF behaves normally.

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 8

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 9

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.