Closed Bug 764656 Opened 10 years ago Closed 7 years ago

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

Categories

(Firefox :: Untriaged, defect)

11 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 318253

People

(Reporter: steve_goers, Unassigned)

References

Details

Attachments

(1 file)

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.
Summary: Users propmted for credentials when Firefox gets into a state where it does not properly perform NTLM authentication → Users prompted for credentials when Firefox gets into a state where it does not properly perform NTLM authentication
Duplicate of this bug: 764655
Some similar bugs:
+ Bug 318253
+ Bug 750621
Bug 318253 ended up arriving at the same conclusion (NTLM authentication is flawed), but I'd still like to thank the original reporter for the thorough description.
Thanks to Stefan Weiss [:sir_none] for pointing out the dupe.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 318253
You need to log in before you can comment on or make changes to this bug.