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

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect, P3)

Description

[Mike Ely]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.0) 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:
http://marc.info/?l=squid-users&m=126645187509866&w=2

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

[Mike Ely]

Adding jduell to CC per suggestion from dholbert in #developers.  I'm idle there as gloin.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Could this be related to bug 542318 somehow?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

[Mike Ely]

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

Comment 5

[Mike Ely]

If there's a packet dump or similar I can gather to help this ticket along, please let me know.

Comment 6

[Jason Duell]

Adding Jim Mathies in case his recent NTLM work is relevant

Comment 7

[Mike Ely]

Attachment: HTTP log when problem occurs (inetcpl is set to auto-detect)

Comment 8

[Mike Ely]

Attachment: HTTP log when problem does not occur (inetcpl is not set to auto-detect)

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

[Mike Ely]

Boris, sorry for the crud at the beginning.  The fun begins when I start hitting up.flickr.com

Comment 11

[Boris Zbarsky [:bzbarsky]]

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 ...

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

[Mike Ely]

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.

Comment 14

[Honza Bambas (:mayhemer)]

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

[Mike Ely]

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

[Mike Ely]

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

[Mike Ely]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

[Mike Ely]

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...

Comment 21

[Honza Bambas (:mayhemer)]

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

[Mike Ely]

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

[Michelle Sintov]

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

Comment 24

[Mike Ely]

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

[Mike Ely]

Attachment: Stack trace of failed upload attempt and subsequent crash after failed auth challenge

Comment 26

[Michelle Sintov]

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

Comment 27

[Mike Ely]

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

Comment 28

[Charles]

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

Comment 29

[Mike Ely]

Wondering about status again.

Comment 30

[Firefox Bug Husbandry Bot]

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

Comment 31

[Firefox Bug Husbandry Bot]

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

Comment 32

[Alin Ilea, Desktop QA]

Marking this as Resolved > Incomplete since the last real activity on this issue was 6 years ago and it might not be relevant anymore (adobe flash no longer supported). Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.