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

Status: RESOLVED DUPLICATE of bug 249942

(Core Graveyard :: Security: UI, enhancement)

Description

[SineSwiper]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16) 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:1.9.2.16) 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:

http://bisharepoint/Pages/Default.aspx

GET /Pages/Default.aspx HTTP/1.1
Host: bisharepoint
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16) 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
MicrosoftSharePointTeamServices: 12.0.0.6421
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

Comment 1

[SineSwiper]

Fixing some tags.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Bug would need to be confirmed to be blocking Firefox 5 or 6.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Bug 237586 suggests that this works in general...

Comment 4

[SineSwiper]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

SineSwiper, Firefox 6 is the current development tip.  See http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

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 https://developer.mozilla.org/en/HTTP_Logging would be a good start.

Comment 6

[SineSwiper]

Confirmed to be a problem with Firefox 4.0.

Headers:
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
MicrosoftSharePointTeamServices: 12.0.0.6421
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:

http://www.resonatorsoft.org/cgi-bin/www-auth.pl?wa1=Basic - Works; asks for UN/PW
http://www.resonatorsoft.org/cgi-bin/www-auth.pl?wa1=Negotiate - Fails; does nothing (breaks RFC4559)
http://www.resonatorsoft.org/cgi-bin/www-auth.pl?wa1=NTLM - Works; asks for UN/PW
http://www.resonatorsoft.org/cgi-bin/www-auth.pl?wa1=Negotiate,+NTLM - Fails; does not support multiple authentications (which breaks RFC2617, section 4.6)
http://www.resonatorsoft.org/cgi-bin/www-auth.pl?wa1=Basic,+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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Thanks for putting up the testcase.

Honza, can you take a look?

Comment 8

[SineSwiper]

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

Comment 9

[SineSwiper]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[SineSwiper]

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.

Comment 12

[SineSwiper]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

IE's default behavior is just insecure, for what it's worth: it leaks your Windows username to random servers.

Comment 14

[SineSwiper]

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.

Comment 15

[Philip Chee]

<https://developer.mozilla.org/en/Integrated_Authentication>
"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."

WONTFIX?

Comment 16

[SineSwiper]

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

Comment 17

[Asa Dotzler [:asa]]

un-setting inappropriately set tracking flags.

Comment 18

[Philip Chee]

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

Comment 19

[SineSwiper]

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.

Comment 20

[Asa Dotzler [:asa]]

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

Comment 21

[SineSwiper]

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.

Comment 22

[Honza Bambas (:mayhemer)]

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.