No UI for "WWW-Authenticate: Negotiate" / SPNEGO in Firefox; Works in IE



8 years ago
3 years ago


(Reporter: Bugzilla-Mozilla, Unassigned)


(Blocks 2 bugs, {testcase})

2.0 Branch
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110319 Firefox/3.6.16 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110319 Firefox/3.6.16 (.NET CLR 3.5.30729)

Sites using the "WWW-Authenticate: Negotiate" header do not work in Firefox.  Instead, it returns a blank page and does not do anything else.  Here is an example set of send/receive headers:


GET /Pages/Default.aspx HTTP/1.1
Host: bisharepoint
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110319 Firefox/3.6.16 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/7.0
WWW-Authenticate: Negotiate
X-Powered-By: ASP.NET
Date: Fri, 22 Apr 2011 18:53:55 GMT
Content-Length: 0

The Negotiate protocol is specified in RFC4559, and the SPNEGO protocol is specified in RFC4178.  I'm not sure exactly which protocols Firefox supports currently, except that I know that NTLM is supported in Firefox.

NTLM is not recommended by Microsoft, as it is an older protocol that does not support recent cryptographic methods.  They recommended the Negotiate protocol, which asks if Kerberos or NTLM is supported and uses one or the other.

Therefore, based on the level of support Firefox provides for the protocols, the root cause could be one of the following:

1. Firefox does not support the Negotiate protocol, or is broken.
2. Firefox does not support the SPNEGO protocol (which contradicts what Wikipedia says), or is broken.
3. Firefox thinks that it can use Negotiate via Kerberos, but it somehow breaks before it bothers to send anything.
4. Firefox requires some sort of buried config option (like network.negotiate-auth.trusted-uris) for this to work.  Buried config options aren't solutions, and make the problem worse because people think the bug is "fixed" when it actually isn't.

I do not know if multiple WWW-Authenicate headers would fix the problem, but seeing as that is also a server-side bandaid, that doesn't actually fix the issue, either.

Reproducible: Always

Steps to Reproduce:
1. Go to site (internal work site, sorry)

Actual Results:  
Blank page

Expected Results:  
Web Page
Fixing some tags.
Version: unspecified → 3.6 Branch
Component: Security → Networking: HTTP
Product: Firefox → Core
QA Contact: firefox → networking.http
Version: 3.6 Branch → 1.9.2 Branch
Bug would need to be confirmed to be blocking Firefox 5 or 6.
Bug 237586 suggests that this works in general...
What's Firefox 6?  Firefox 4 is the latest stable release.  I will try it with Firefox 4.

Boris, the bug is too old to be considered a fix for this issue.
SineSwiper, Firefox 6 is the current development tip.  See

As for that bug, the point is that "WWW-Authenticate: Negotiate" is implemented.  So it's not that it doesn't work at all; rather it doesn't work in your particular case.  Which means that to get anywhere we need to know what's special about your particular case....

Attaching a full HTTP log of the interaction per would be a good start.
Confirmed to be a problem with Firefox 4.0.

GET /Pages/Default.aspx HTTP/1.1
Host: bisharepoint
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/7.0
WWW-Authenticate: Negotiate
X-Powered-By: ASP.NET
Date: Mon, 25 Apr 2011 17:07:24 GMT
Content-Length: 0

I have some test cases here, since the original site is private.  This is on an Apache server, just as a script to print the correct headers, but it still responds the same.  Here's some various cases and results: - Works; asks for UN/PW - Fails; does nothing (breaks RFC4559) - Works; asks for UN/PW,+NTLM - Fails; does not support multiple authentications (which breaks RFC2617, section 4.6),+Negotiate,+NTLM - Fails; does not support multiple authentications (which breaks RFC2617, section 4.6)

According to the SPNEGO Wiki page, Firefox implemented the Negotiate extension way back in Firefox 0.9.  If it had worked at one time, it is completely broken now.  Does not work in FF 3.6, and does not work in 4.0.
Thanks for putting up the testcase.

Honza, can you take a look?
Ever confirmed: true
I also have Firefox HTTP debug logs.  Here's the last part, which looks to be the relevant piece:

0[52d140]: nsHttpChannel::OnStartRequest [this=75e7d70 request=96f2560 status=0]
0[52d140]: nsHttpChannel::ProcessResponse [this=75e7d70 httpStatus=401]
0[52d140]: nsHttpHandler::NotifyObservers [chan=75e7da0 event="http-on-examine-response"]
0[52d140]: nsHttpChannelAuthProvider::ProcessAuthentication [this=961ffb0 channel=75e7e74 code=401 SSLConnectFailed=0]
0[52d140]: nsHttpChannelAuthProvider::PrepareForAuthentication [this=961ffb0 channel=75e7e74]
0[52d140]:   proxy continuation state has been reset
0[52d140]: nsHttpChannelAuthProvider::GetAuthenticator [this=961ffb0 channel=75e7e74]
0[52d140]: nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=961ffb0 channel=75e7e74 proxyAuth=0 challenges=Negotiate]
0[52d140]: nsHttpChannelAuthProvider::GetIdentityFromURI [this=961ffb0 channel=75e7e74]
0[52d140]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://bisharepoint:-1 realm=]
0[52d140]: unable to authenticate
0[52d140]: ProcessAuthentication failed [rv=80004004]
0[52d140]: nsHttpChannelAuthProvider::CheckForSuperfluousAuth? [this=961ffb0 channel=75e7e74]
0[52d140]: nsHttpChannel::ProcessNormal [this=75e7d70]
0[52d140]: nsHttpChannel::ProcessFallback [this=75e7d70]
0[52d140]:   choosing not to fallback [0,,0]
0[52d140]: nsHttpChannel::InitCacheEntry [this=75e7d70 entry=a2bcca0]
0[52d140]: nsHttpResponseHead::MustValidate ??
0[52d140]: Must validate since response is an uncacheable error page
0[52d140]: nsHttpChannel::AddCacheEntryHeaders [this=75e7d70] begin
0[52d140]:   calling mListener->OnStartRequest
0[52d140]: HttpBaseChannel::ApplyContentConversions [this=75e7d70]
0[52d140]: Preparing to write data into the cache [uri=http://bisharepoint/Pages/Default.aspx]
0[52d140]: nsHttpChannel::InstallCacheListener async tee a2bd360
0[52d140]: nsHttpChannel::OnStopRequest [this=75e7d70 request=96f2560 status=0]
0[52d140]: nsHttpTransaction::DeleteSelfOnConsumerThread [this=961fe00]
0[52d140]: Destroying nsHttpTransaction @961fe00
0[52d140]: nsHttpChannel::FinalizeCacheEntry [this=75e7d70]
0[52d140]:   calling OnStopRequest
This apparently only works if the domain in question is put into the network.negotiate-auth.trusted-uris config option.  Therefore, I'm changing the nature of this bug.

Adding domains to hidden configuration options is far from a solution.  Apparently, this band aid has been allowed to exist for years without a UI.  The protocol works flawlessly in IE.  The site opens up and it works.  No hidden and undocumented configuration required.  Sure, it's a Microsoft browser on a Microsoft web server.  However, Microsoft actually did the right thing and published the RFCs.

The problem is two-fold:

1. There is no UI for this Negotiate domain option.  No prompt saying "Would you like to authenticate here?" or Preferences menu list of domains (even as an add-on to the Saved Passwords screen).  This breaks User Experience Principles: Control, Discovery, Error-Prevention, Implementation-Level, and UserFeedback.  I'll keyword this bug as such.

2. If trusted-uris is fully open, Firefox seems to broadcast the Authenticate first before finding out that it's a Negotiate request.  It doesn't seem to happen on all sites, but Firebug shows the request with the header first, before figuring out that it's actually needed.  This may just been a caching thing that I'm missing.
Component: Networking: HTTP → Security: UI
QA Contact: networking.http → ui
Summary: Web Sites with "WWW-Authenticate: Negotiate" do not work in Firefox; Works in IE → No UI for "WWW-Authenticate: Negotiate" / SPNEGO in Firefox; Works in IE
Version: 1.9.2 Branch → 2.0 Branch
The reason we don't do Negotiate by default is that last I checked it uses your Windows login credentials by default, which we don't want to expose to random sites....
Found other related bugs (including a meta bug), so I'm adding them to the blocked list.  Somebody should merge them altogether, though I'm not sure if that's possible without simply marking them as dupes.

For the record, it appears this has been requested since 2004.  I wish there was an "way-too-old" keyword.
blocking2.0: --- → ?
Keywords: common-issue+
Boris, that is understood, but a UI should still prompt to add the domain to the list.  Again, IE works without any prompts or anything.  This would be the best solution, but given that I don't know if there is some default option in IE causing it to work or something deep within AD/Windows/IE, I'm not sure if it's possible or not within Firefox.

Perhaps somebody better familiar with the protocol can answer that question and we can potentially make it much more intuitive than even a Yes/No question.
IE's default behavior is just insecure, for what it's worth: it leaks your Windows username to random servers.
As long as it isn't a password, that seems alright.  If it's still a concern, we can just put in the UI Yes/No prompt.  That would be much better than what it's doing now, which is a errorless blank screen.
"Mozilla currently supports a whitelist of sites that are permitted to engage in SPNEGO authentication with the browser. This list is intended to be configured by an IT department prior to distributing Mozilla to end-users."

I completely disagree, based on the following reasons:

1. What IT dept actually supports Firefox as an official browser?  Relatively few, and bugs like this are one reason why.  "Why would we support this browser?  It can't even access our SharePoint site!"

2. The page comes up as nothing.  It's blank.  No error message.  No prompt for more access.  No help.  No indication that it did something.  This breaks the User Experience Principles I outlined above, and it breaks common sense.

The only reason why I figured it out is because I'm a web programmer by trade and I've been digging into HTTP headers, RFCs, and debug logs.  Oh, and some obscure Mozilla bug that mentions the above configuration option.  Your Average Joe is -NOT- going to figure it out, and is going to assume that Firefox sucks because IE can open the site just fine.  No planned hindrance should require a user to dive into HTTP headers to figure out, and no planned solution should require a user to find obscure documentation buried in a bug report to fix.

3. It has been requested already.  Many times, in the past -seven years-.  People would like to make sure the browser just works they way it should.  

4. WONTFIX is generally a lazy answer.  I understand and respect the workload of OSS developers, but I have seen bugs like this go for TEN YEARS for really popular issues (bug 61098 is a good example).  Frankly, that's a horrible track record.  Let's not have that be the gold standard for the most popular web browser on the planet.

This breaks the basic functionality of Firefox going to a web site and having it pop up.  This isn't about CSS not rounding corners, or a live bookmark not showing favorite icons.  This about entire web sites showing up as blank.  Firefox main purpose is to -browse web sites-!
un-setting inappropriately set tracking flags.
blocking2.0: ? → ---
Henry IV, part 2 | Act 4, Scene 5:

"When thou dost pinch thy bearer, thou dost sit
Like a rich armour worn in heat of day,
That scalds with safety."
Keywords: 4xp
Sorry, you could give me a Hamlet reference and I would know it, but I haven't read Henry IV.  I think I get the jist, though.

Tracking flags, fine.  I thought ? meant to look at whether it's worth tracking.

I disagree with the keyword removals.  It still breaks User Experience Principles.  Prove that it doesn't.  A blank screen is not a proper user experience.

And this isn't an enhancement request.  It's a UI bug.  The Negotiate protocol was created, and instead of properly implementing a UI, it was buried in the config.  It would be like turning off FTP, putting the switch in about:config, and saying that it's a enhancement request to put the switch in the UI.

Heck, I'm fine with using bug 249942 as the original and duping the rest (except meta bug 250014), just as long as the ticket gets properly re-coded.  Otherwise, it's probably going to sit for another 7 years.
(In reply to comment #19)

> Otherwise, it's probably going to sit for another 7 years.

I'm fine with it sitting for another 7 years. This is not a priority for Firefox and flags and keywords do not change that. *New* information about the number of Firefox users experiencing the problem or a patch to the problem might change that.
I'd write one, but I'm not good at UI, and this is mostly a UI problem.

And I guess this one is going to have to blow up in your face before it gets fixed.  Fine, we'll just wait for Basic/NTLM auth to get largely replaced by Negotiate.
SineSwiper, you can always create an extension that implements what you want and distribute it (best in open fashion) to people.  

Bug 249942 is about what you are asking and your extension could be a good workaround, maybe one day adopted to Firefox code.  This bug is a dupe of that bug.
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 249942
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.