764655 - Users propmted for credentials when Firefox gets into a state where it does not properly perform NTLM authentication

Status: RESOLVED DUPLICATE of bug 764656

(Firefox :: Untriaged, defect)

Description

[Steve Goers]

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.30 Safari/525.13

Steps to reproduce:

Firefox is set up in an explicit proxy deployment.  It is installed on a Windows machine that is joined to a local domain.  

The proxy is performing native NTLM authentication, and are expecting they do not receive authentication prompts when browsing through the proxy.


Actual results:

It appears that Firefox gets into a state where it does not perform NTLM authentication properly.  For proper NTLM authentication, the NTLM Negotiate, NTLM Challenge, and final NTLM Authenticate step must be done in one tcp connection.

**Please note: All referenced images and captures are attached to BZ in Firefox_proxy_auth_issue.zip.  All of the .png files are filtered out of 'capture2.trace', included in the attached .zip.

First, look at image '2450.png'.  The file being requested is "http://rtm.ebaystatic.com/0/RTMS/Image/MERC_Horizontal_DadsnGrads-ToysForDads_Q212_825x271.jpg"  

Using the Wireshark filter "tcp.port eq 2450" (or "tcp.stream eq 0"), the image file is requested in packet 4. The proxy responds with the 407 in packet 12, but Firefox then interrupts itself and responds with a GET for a javascript file (rcoelihdo21zfckjx5i1too0s.js) with a valid NTLMSSP_NEGOTIATE flag in packet 14. The auth then succeeeds and the connection is closed by the client after the javascript is delivered.

Next, look at image "2456.png"  Using the Wireshark filter "tcp.port eq 2456", we can see that there is a different image (imgEd.jpg) being requested in packet 9.  The proxy sends and expected 407 in packet 20 but Firefox again interrupts the connection to request the original image file (from the request above) in packet 23 with the NTLMSSP_NEGOTIATE. The proxy sends the NTLMSSP_CHALLENGE in packet 44, but Firefox then closes the connection immediately.

It appears that the authentication prompt occurs as a result of the following:

Using the filter "tcp.port eq 2478" (and looking at image "2478.png"), we can see that Firefox opens a new tcp connection to respond to the CHALLENGE that was sent in packet 44 above (2456.png), and starts this connection off with a reqeust for the image in packet 55, but includes the NTLMSSP_AUTH information. This is not valid as the negotiate, challenge and auth must happen in the same tcp connection, so the proxy correctly sends back a 407 in packet 58.

Lastly, using the filter "tcp.port eq 2509" (and looking at image "2509.png"), shows a successful authentication attempt when valid credentials are submitted into the prompt box.  The file is then successfully retrieved (as indicated by the 12 second gap before the 200 OK response).  

This type of behavior is seen multiple times in the capture file "coaching2.trace" and there's many more examples of Firefox opening new connections and starting off with the wrong auth step and tripping over itself by requesting different files in the middle of the auth negotiation.





Expected results:

We would expect that the NEGOTIATE, CHALLENGE, and AUTHENTICATE step all occur within one tcp connection.  While it is valid that a new tcp connection is established when the browser sends the NEGOTIATE to the proxy, but the CHALLENGE (and subsequent client AUTHENTICATE) should occur in that same tcp connection.