NTLM SSO breaks passing auth to Flash iff "Auto detect" is enabled both in Windows AND Firefox




8 years ago
3 months ago


(Reporter: Mike Ely, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ntlm][necko-backlog], URL)


(3 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100115 SUSE/3.6.0-1.2 Firefox/3.6
Build Identifier: 3.0 and up

See the following thread at squid-users for added info, looks a lot more like a Firefox bug:

Basically if the Windows internet settings are set to auto-detect and Firefox proxy settings are also set to auto-detect, certain CONNECT attempts will result in an authentication pop-up despite the fact that SSO is otherwise working.  Tested on various machines, totally reproducible.

Reproducible: Always

Steps to Reproduce:
1.  Enable "Auto-detect" for proxy in Firefox and inetcpl.  Verify on proxy that WPAD is being picked up and that user session is being logged with AD username.
2.  In Firefox, go to Flick (as an example) and attempt to upload a photo.  An auth pop-up will appear and the upload will not complete.
3.  DISABLE "Auto-detect" in the Windows control panel but leave it ENABLED in Firefox.  The upload will now complete successfully.

In environments where IE has to be maintained as a secondary browser for ActiveX work-related sites, this is a death blow.  I've verified this problem exists on various versions of Firefox starting at 3.0.something all the way through current 3.6 and on different computers.  IE version does not appear to be dependent either.

What I personally find the most striking about this is how the Windows Control Panel settings toggle this problem on and off.  It _may_ be a good pointer on where this bug is coming from.

Comment 1

8 years ago
Adding jduell to CC per suggestion from dholbert in #developers.  I'm idle there as gloin.
Could this be related to bug 542318 somehow?
Ever confirmed: true
I just checked with Mike on IRC, by the way, and this appears in 3.0 and 3.5 as well, not just 3.6, so it's not related to the POST issues with proxies in 3.6 either, since those are new since 3.5.

Comment 4

8 years ago
Per Boris's suggestion, I re-tested with a daily (Gecko/20100225 Minefield/3.7a2pre) and the behavior was unchanged.

Comment 5

8 years ago
If there's a packet dump or similar I can gather to help this ticket along, please let me know.
Adding Jim Mathies in case his recent NTLM work is relevant

Comment 7

8 years ago
Created attachment 429573 [details]
HTTP log when problem occurs (inetcpl is set to auto-detect)

Comment 8

8 years ago
Created attachment 429574 [details]
HTTP log when problem does not occur (inetcpl is not set to auto-detect)
Mike, which URI are you loading (or think you might be loading; that log has a lot of garbage up front like the Firefox default homepage) when this happens?

Comment 10

8 years ago
Boris, sorry for the crud at the beginning.  The fun begins when I start hitting up.flickr.com
Hmm.  So you load http://up.flickr.com/crossdomain.xml and get back an HTTP 200, right?  I see no mention of anything auth-related in the failing log after that GET for http://up.flickr.com/crossdomain.xml ...
In particular, in the failing log I don't see a POST happening to http://www.flickr.com/services/rest/.  Should there be?

Comment 13

8 years ago
I wish I understood the problem better.  As it stands, we get a Windows (not Firefox) auth prompt when trying to upload a photo to Flickr.  It's somewhere in that set of calls that the breakage happens.  I didn't see the post either, am wondering if they're using some other method.
Are they using Flash?  If so, Flash is using windows (IE) API to do the networking.  That completely bypasses what Firefox knows about authenticated sessions.

Comment 15

8 years ago
Honza, I don't see any Flash calls (although Flickr certainly loves itself some Flash) in this instance, and in the other work-related site where the same behavior occurs, there are no Flash assets at all, but plenty of javascript.  

Beyond that, when IE is configured to auto-detect the problem happens, but when IE is not configured to auto-detect, the problem goes away, which would be counter to the notion that Flash's calls to that part of the networking stack are causing breakage.

Comment 16

8 years ago
I was wrong about this.  After disabling Flash, I get a whole other uploader from Flickr and it works fine.  For the work-related site the "Browse" button isn't even selectable with Flash disabled.

All of which is interesting, but what to do about it?  NTLM works fine in IE, and it works mostly fine in Firefox, so how do we pass auth back and forth between Firefox and Flash?  For verification, I was able to use the same Flash uploader in IE with no issues.


8 years ago
Summary: NTLM SSO prompts during certain CONNECT iff "Auto detect" is enabled both in Windows AND Firefox → NTLM SSO breaks passing auth to Flash iff "Auto detect" is enabled both in Windows AND Firefox
Hmm.  When you use IE, do you have to authenticate once (presumably when loading your first web page) and then it just works?

And if so, in the Firefox case do you just have to authenticate once in Firefox, and then it just works?

And if so...  If you start IE and authenticate in it, do you still end up with two authentication prompts in Firefox?

Comment 18

8 years ago
Never have to auth at all.  Authentication is being pulled from the user's AD session.  With Firefox it Just Works until I hit that uploader, and with IE it just works all the way through the uploader.  Meanwhile I tail the proxy logs and see the usernames going along with the GET requests.
That's really weird... unless Flash actually has different network code in the NPAPI and ActiveX plug-ins (unlikely, I would think).

Michelle, any idea what Flash is doing here?

Comment 20

8 years ago
Interestingly, word is from the work-related site which prompted this issue that they are using something called the "Yahoo User Interface" as a core component of their Flash-based uploader.  One might presume that Flickr's uploader uses the same technology...
I had already faced similar issue with Flash uploader in bug 422180 comment 13.  The server Flash was trying to upload to was using an invalid certificate.  Firefox was told to bypass the certificate error (by a certificate exception) but the Flash uploader still wasn't able to upload because of a certificate problem.  

I found out that Flash was not using Firefox NPAPI to establish connection for upload but was using a completely different API, most likely IE API.

Comment 22

8 years ago
Interesting.  Wonder why adding a proxy into the mix would trigger something similar.  Hypothesis: the same core issue as in 422180 is occurring here but Adobe managed to gloss over it - until you add an authenticated proxy session for Firefox.

Comment 23

8 years ago
The Flash Player uses the WinINet stack to do file uploads (and the Mozilla stack to do file downloads).

Comment 24

8 years ago
Michelle, I filed a bug with Adobe on this but made the mistake of tagging it "Security" and it subsequently vanished.  Do you have any access there?

Comment 25

8 years ago
Created attachment 430189 [details]
Stack trace of failed upload attempt and subsequent crash after failed auth challenge
Attachment #430189 - Attachment mime type: application/octet-stream → text/plain

Comment 26

8 years ago
Here is the Adobe bug (no longer tagged "Security"): https://bugs.adobe.com/jira/browse/FP-4051

Comment 27

8 years ago
Thanks, Michelle.  What's a typical activity level on a bug there?  I've posted a couple of questions with no response.

Comment 28

8 years ago
Mike that's my fault.  We've been heads down in other work.  Let me take a look.

Comment 29

8 years ago
Wondering about status again.
Whiteboard: [ntlm][necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.