1023748 - Allow NTLMv1 over SSL/TLS, or intranet access is broken on Firefox 30 for non-Windows platforms

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Boris Glawe]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

I try to open the URL of our internal MS sharepoint site with Firefox 30.0 for Mac (Mavericks).

All my colleagues have to some trouble.


Actual results:

I retrieve an empty page (no html code at all). I deleted all cache, cookies, active logins, etc. But still doesn't work.


Expected results:

page should open or at least some html code should retrieved.

Comment 1

[Boris Glawe]

I have to mention: It works perfectly with Firefox version 30.0 for Windows 7.

Comment 2

[Boris Glawe]

... and it worked perfectly with MAC until the update to version 30.0, yesterday.

Comment 3

[Boris Glawe]

... and we are using Sharepoint 2010.

Alle installed addons are deactivated but it still doesn't work.

Comment 4

[Patrick Weiden]

In addition to the above said, there should first appear a popup asking for your username and password. After inserting the values, one is getting the Sharepoint site.

Comment 5

[Boris Glawe]

Hi Patrick,

the login popup does not appear.

I agree, that this might be the correct path to the source of our problem.

Comment 6

[Boris Glawe]

The site is a https site with an officially signed (not self signed) certificate. Firefox does not report any problems with the certificate.

Comment 7

[Boris Glawe]

Same issue with Firefox 30.0 for Android.

Comment 8

[Patrick Weiden]

(In reply to Boris Glawe from comment #7)
> Same issue with Firefox 30.0 for Android.

I can confirm this. With Firefox 29.0.1 on Android the page worked like a charm. With Firefox 30, I just see a white page, while the lock in the URL bar is locked.

Comment 9

[Quentin Headen [:qheaden]]

I can also confirm this problem in Linux. I am using Linux Mint 16 64-bit, and I get a 401 Unauthorized message when trying to visit my organization's Sharepoint page. FWIW, I was also using the 64-bit version of Firefox 30.

Comment 10

[Quentin Headen [:qheaden]]

In addition, the website I am having trouble with is using HTTPS and requires a log in.

Comment 11

[Kohei Yoshino]

As described here, NTLMv1 auth has been disabled, and there's a workaround for OS X and Linux users:

https://developer.mozilla.org/en-US/Firefox/Releases/30/Site_Compatibility#Security

Comment 12

[Boris Glawe]

Hi Kohei,

Thanks for the hint/link! This explains a lot.

Is there a best practice for Sharepoint 2010 to enable any non-Windows compatible Authentication on the server side? I expect that many Firefox users will complain about failing authentication, as both Firefox and Sharepoint are widely used.

Comment 13

[Kohei Yoshino]

I think there's no server-side workaround for this issue. Non-Windows users can

* Type about:config in the location bar
* Click the "I'll be careful" button
* Find network.negotiate-auth.allow-insecure-ntlm-v1
* Double-click on it to change the value to true

Comment 14

[Boris Glawe]

Thanks for the immediate reply.

I've sucessfully verified this solution already. We have many many users with non-windows machines (Mac, Android, Linux, ...) accessing the sharepoint server. I don't feel comfortable to recommend them to use an insecure authentication method on purpose.

It feels like Firefox has a real security issue here!? Of course it's the problem of the protocol and not of Firefox. However all days life forces many users to stick to this insecure protocal as there's no alternative. What's your opinion?

Comment 15

[Kohei Yoshino]

I'm not affected, but as an OS X user, I'm concerned about this. Follow Bug 828183 for further discussion.

Comment 16

[Nick Lowe]

BTW: Google Chrome has exectly the same security concern, Boris. The only browser on a Mac that presently does not, offering NTLMv2 support, is Safari.

Comment 17

[Nick Lowe]

There is another smarter alternative too that should probably be implemented if-and-until an internal NTLMv2 implementation is available in Firefox.

At the moment, the allow-insecure-ntlm-v1 preference affects connections via HTTP and HTTPS.

The implementation could be enhanced so that it always allows NTLMv1 where the connection is via HTTPS (SSL/TLS) as there is no vulnerability in this scenario.

Where a connection is over HTTP defer to the allow-insecure-ntlm-v1 preference and leave this disabled by default. (NTLMv1 is only insecure where it is naked.)

Comment 18

[Boris Glawe]

Thanks for you support so far. I think, we can close this bug and/or mark it as duplicate of 828183. We'll follow this bug.
We'll stick to NTLMv1+HTTPS until there are alternatives available.

Best regards

Boris

Comment 19

[Kohei Yoshino]

It would be nice if Nick's solution could be implemented in Firefox 30.0.1 if available, since we have got many feedbacks and this is the biggest compatibility issue in Firefox 30:

https://docs.google.com/spreadsheets/d/1048AVpvbP3O2atsV3i--xLpHCr4PR7TGXyFtgMrvt6Q/edit#gid=89642089

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Since 31 is an ESR, I will probably take a patch for this bug.

Comment 23

[Patrick McManus [:mcmanus]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #22)
> Since 31 is an ESR, I will probably take a patch for this bug.

its fine to track this and set a date for discussing it with more feedback, but at this point we aren't planning on a patch. The issue is a result of closing a security hole.

Comment 24

[Kohei Yoshino]

Comment 17 (and the bug summary) has a possible, secure solution. If the 30.0.1 chemspill is coming, I believe this should be fixed since it's still the biggest site compatibility issue of 30.

Comment 25

[Lukas Blakk [:lsblakk] use ?needinfo]

We would not take a "possible" solution, without testing over the course of a Beta, to a 30.0.1 (chemspill or otherwise).  The main issue has a workaround, is noted in the release notes and the dev docs.

Comment 26

[Lukasz Szybalski]

Hello,
Reading the comments on here:

1. Is the issue that NTLMv2 is not supported by Firefox on Linux?
or
2. Microsoft does not allow NTLMv2 on "non windows" platform browsers?

If #1 then obviously this ticket should be reopened, unless there is a ticket for 'Debian' or 'Ubuntu' for example.
If #2 is there a ticket request with Microsoft? That would sound like a major "discrimination" that could have legal implication for Microsoft.

or is it something else?
Thank you
Lucas

Comment 27

[MattyD]

From my understanding Firefox uses a system API for authentication on Windows (by default). The decision to force NTLM v2 depends entirely on the client settings.

Linux / OSX doesn't have a similar library available for FF to use, so it has been using its own module for NTLM authentication instead. This module doesn't yet support NTLM v2 so it has been disabled by default. Changing the allow-insecure-ntlm-v1 preference will re-enable it.

Comment 28

[Honza Bambas (:mayhemer)]

Attachment: v1

This introduces a new pref "network.negotiate-auth.allow-insecure-ntlm-v1-https-only" that is by default |true|.  To https:// sites we will by default authenticate using NTLMv1.  

For http:// it's tho still disabled, that is left under control by the famous "network.negotiate-auth.allow-insecure-ntlm-v1" that is still left by default at |false|.

Comment 29

[Patrick Weiden]

Dear Honza,

the new pref and the NTLMv1 default values that you introduce above sound very good and reasonable, especially for my setting. Could you please give me some indication in which version of Firefox it will be introduced? This would be helpful...

Thanks in advance,
Patrick

Comment 30

[Honza Bambas (:mayhemer)]

Attachment: v1.1 [buildable on gcc]

Comment 31

[Honza Bambas (:mayhemer)]

(In reply to Patrick Weiden from comment #29)
> Dear Honza,
> 
> the new pref and the NTLMv1 default values that you introduce above sound
> very good and reasonable, especially for my setting. Could you please give
> me some indication in which version of Firefox it will be introduced? This
> would be helpful...
> 
> Thanks in advance,
> Patrick

Hi, it's very likely this will land for 33.  Then we can try to uplift to 32 and *maybe* 31, but definitely 31 is not that likely to happen, although not completely impossible too.

Comment 32

[Jason Duell]

Comment on attachment 8444017 [details] [diff] [review]
v1

Review of attachment 8444017 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/http/nsHttpNTLMAuth.cpp
@@ +32,5 @@
>  static const char kAllowNonFqdn[] = "network.automatic-ntlm-auth.allow-non-fqdn";
>  static const char kTrustedURIs[]  = "network.automatic-ntlm-auth.trusted-uris";
>  static const char kForceGeneric[] = "network.auth.force-generic-ntlm";
> +static const char kAllowGenericHTTP[] = "network.negotiate-auth.allow-insecure-ntlm-v1";
> +static const char kAllowGenericHTTPS[] = "network.negotiate-auth.allow-insecure-ntlm-v1-https-only";

Let's call it "network.negotiate-auth.allow-insecure-ntlm-v1-https".  The -only part makes it sound like it will disallow http, but it actually only controls https (i.e. if both this and "network.negotiate-auth.allow-insecure-ntlm-v1" are set, we allow both http/https, but a simple reading of a pref named -only would make it seem that we'd only support https).

@@ +203,5 @@
> +    channel->GetIsSSL(&isSSL);
> +    if (!isSSL)
> +        return false;
> +
> +    nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);

I assume we're on the main thread when this gets called?  I.e is nsHttpNTLMAuth::ChallengeReceived() called on the main thread?  Let's put in a MOZ_ASSERT that we're on the main thread at the top of this function.

Comment 33

[Jason Duell]

Comment on attachment 8444017 [details] [diff] [review]
v1

Review of attachment 8444017 [details] [diff] [review]:
-----------------------------------------------------------------

Looks like the other patch is the one we want.

Comment 34

[Jason Duell]

Comment on attachment 8444176 [details] [diff] [review]
v1.1 [buildable on gcc]

Review of attachment 8444176 [details] [diff] [review]:
-----------------------------------------------------------------

This is the patch we want (both for gcc compat, and because the other one is missing the change to all.js)

Comment 35

[Honza Bambas (:mayhemer)]

(In reply to Jason Duell (:jduell) from comment #32)
> I assume we're on the main thread when this gets called?  I.e is
> nsHttpNTLMAuth::ChallengeReceived() called on the main thread?  Let's put in
> a MOZ_ASSERT that we're on the main thread at the top of this function.

Jason, when you look at the code, you can see these pref access helper functions are already called from ChallengeReceived that is (right now) called only on MT.  So I don't think we need that MOZ_ASSERT, but I'll gladly add it.

Thanks.

Comment 36

[Jason Duell]

Comment on attachment 8444176 [details] [diff] [review]
v1.1 [buildable on gcc]

It's rare that I ask for something to get uplifted all the way to release (and I understand if it's not possible) but this one seems to merit it.  With this patch we can get at least https:// support working for NTLM servers, which otherwise users can't connect to any more without changing an about:config pref (and that's a hurdle for many users).

It also allows/encourages site admins using NTLM to upgrade http:// links to https:// and get their users using NTLM w/o pref changes, which is an outcome that's more secure than having users opt-in to insecure http+NTLM.

Finally the code is literally as simple as "if using HTTPS, revert to old codepath".

[Approval Request Comment]
Regression caused by (bug #): 828183
User impact if declined: Users aren't able to connect to servers using NTLM authorization unless they change a pref (which is a high bar for some users).
Testing completed (on m-c, etc.): by hand.  Very small change.
Risk to taking this patch (and alternatives if risky):  Very low and only affects NTLM codepath.
String or IDL/UUID changes made by this patch: none.

Comment 37

[Honza Bambas (:mayhemer)]

Attachment: v1.2

https://hg.mozilla.org/integration/mozilla-inbound/rev/2ca9a20fb91a

Comment 38

[Honza Bambas (:mayhemer)]

Comment on attachment 8444556 [details] [diff] [review]
v1.2

See comment 36 for approval request comments.

Comment 39

[Robert Kaiser]

(In reply to Honza Bambas (:mayhemer) from comment #31)
> Hi, it's very likely this will land for 33.  Then we can try to uplift to 32
> and *maybe* 31, but definitely 31 is not that likely to happen, although not
> completely impossible too.

Given that 31 is going to be an ESR and this mostly affects enterprise users, I guess there's a good argument for taking it there, though.

Comment 40

[Sylvestre Ledru [:Sylvestre]]

Yeh, I agree with Kairo, especially if it is indeed low risk.

Comment 41

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8444556 [details] [diff] [review]
v1.2

I am approving for aurora + beta to have them in beta4.
About release, Lukas sent an email to User Advocacy to have their opinions on this.

Comment 42

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1a06329ebf36
https://hg.mozilla.org/releases/mozilla-beta/rev/91263283a868

Comment 43

[u279076]

Boris, can you please help us by testing to make sure this is fixed? It should be fixed tomorrow's Nightly, Aurora, and Beta builds.

nightly: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
aurora: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
beta: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/31.0b4-candidates/build1/

Comment 44

[Patrick Weiden]

Dear Anthony,

as I got the same issues Boris had, I have tested our SharePoint website with Firefox 31b4 on Mac OS X Mavericks with the default settings for the two NTLMv1 prefs

network.negotiate-auth.allow-insecure-ntlm-v1: false
network.negotiate-auth.allow-insecure-ntlm-v1-https: true

and can confirm the solution works, i.e., I get the authentication dialog and can authenticate myself to the SharePoint website. As the fix should be the same in all versions (I assume), I have not directly tested the Aurora and Nightly version, but I could do so if explicitly requested...

Thanks a lot for all your help and quick responses!

Kind regards,
Patrick

Comment 45

[Boris Glawe]

Hi Anthony,

I verified this version:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/31.0b4-candidates/build1/

with
network.negotiate-auth.allow-insecure-ntlm-v1 = false
network.negotiate-auth.allow-insecure-ntlm-v1-https = true

It works perfectly! Thanks! I'm looking forward to the firefox 31.0.

Comment 46

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/2ca9a20fb91a

Comment 47

[u279076]

(In reply to Boris Glawe from comment #45)
> It works perfectly! Thanks! I'm looking forward to the firefox 31.0.

Thanks Boris!

Comment 48

[u279076]

(In reply to Patrick Weiden from comment #44)
> Thanks a lot for all your help and quick responses!

Thank you for confirming this works. If you wouldn't mind testing Nightly and Aurora as well, that would be a big help.

Comment 49

[Patrick Weiden]

(In reply to Anthony Hughes, QA Mentor (:ashughes) [Unavailable until July 3, 2014] from comment #48)
> (In reply to Patrick Weiden from comment #44)
> > Thanks a lot for all your help and quick responses!
> 
> Thank you for confirming this works. If you wouldn't mind testing Nightly
> and Aurora as well, that would be a big help.

Dear Anthony, no problem about that.

I tested both versions today on my Mac OS X Mavericks.
- The downloaded version(*) of Aurora (32.0a2) [last modified "24/06/14 09:44:00 am"] works like a charm.
- But the downloaded version(*) of Nighthly (33.0a1) [last modified "24/06/14 11:22:00 am"] only has the old NTLMv1 pref and not the new one (with "-https" at the end), just like the current stable version.

(*) I downloaded the dmg-files for Mac.

Comment 50

[Patrick Weiden]

(In reply to Patrick Weiden from comment #49)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) [Unavailable until July
> 3, 2014] from comment #48)
> > (In reply to Patrick Weiden from comment #44)
> > > Thanks a lot for all your help and quick responses!
> > 
> > Thank you for confirming this works. If you wouldn't mind testing Nightly
> > and Aurora as well, that would be a big help.
> 
> Dear Anthony, no problem about that.
> 
> I tested both versions today on my Mac OS X Mavericks.
> - The downloaded version(*) of Aurora (32.0a2) [last modified "24/06/14
> 09:44:00 am"] works like a charm.
> - But the downloaded version(*) of Nighthly (33.0a1) [last modified
> "24/06/14 11:22:00 am"] only has the old NTLMv1 pref and not the new one
> (with "-https" at the end), just like the current stable version.
> 
> (*) I downloaded the dmg-files for Mac.

Today I successfully tested the Mac version (dmg-file) of Nighthly (33.0a1) [last modified "26/06/14 11:32:00 am"], having both NTLMv1 prefs and working like a charm (with their corresponding standard values).

Comment 52

[Honza Bambas (:mayhemer)]

FYI, a-r has been denied for bug 1030426, so this cannot go to release anymore unless we a-r? again on that bug too.

Comment 54

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8444556 [details] [diff] [review]
v1.2

31 is going to ship next week. So, not taking the patch in release.