Last Comment Bug 1023748 - Allow NTLMv1 over SSL/TLS, or intranet access is broken on Firefox 30 for non-Windows platforms
: Allow NTLMv1 over SSL/TLS, or intranet access is broken on Firefox 30 for non...
Status: RESOLVED FIXED
[qa-]
: dev-doc-needed, regression, site-compat
Product: Core
Classification: Components
Component: Networking (show other bugs)
: 30 Branch
: x86 Mac OS X
-- major with 1 vote (vote)
: mozilla33
Assigned To: Honza Bambas (:mayhemer)
:
: Patrick McManus [:mcmanus]
Mentors:
: 1023925 1024849 1031913 1034562 1079732 (view as bug list)
Depends on: 1030426
Blocks: 828183
  Show dependency treegraph
 
Reported: 2014-06-11 01:18 PDT by Boris Glawe
Modified: 2014-10-08 04:40 PDT (History)
26 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wontfix
+
verified
+
fixed
fixed


Attachments
v1 (5.67 KB, patch)
2014-06-21 16:55 PDT, Honza Bambas (:mayhemer)
jduell.mcbugs: review-
Details | Diff | Splinter Review
v1.1 [buildable on gcc] (6.09 KB, patch)
2014-06-22 17:19 PDT, Honza Bambas (:mayhemer)
jduell.mcbugs: review+
Details | Diff | Splinter Review
v1.2 (6.39 KB, patch)
2014-06-23 10:45 PDT, Honza Bambas (:mayhemer)
honzab.moz: review+
sledru: approval‑mozilla‑aurora+
sledru: approval‑mozilla‑beta+
sledru: approval‑mozilla‑release-
Details | Diff | Splinter Review

Description User image Boris Glawe 2014-06-11 01:18:42 PDT
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 User image Boris Glawe 2014-06-11 01:23:32 PDT
I have to mention: It works perfectly with Firefox version 30.0 for Windows 7.
Comment 2 User image Boris Glawe 2014-06-11 02:11:26 PDT
... and it worked perfectly with MAC until the update to version 30.0, yesterday.
Comment 3 User image Boris Glawe 2014-06-11 02:13:36 PDT
... and we are using Sharepoint 2010.

Alle installed addons are deactivated but it still doesn't work.
Comment 4 User image Patrick Weiden 2014-06-11 02:18:05 PDT
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 User image Boris Glawe 2014-06-11 02:22:06 PDT
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 User image Boris Glawe 2014-06-11 02:24:01 PDT
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 User image Boris Glawe 2014-06-11 02:39:33 PDT
Same issue with Firefox 30.0 for Android.
Comment 8 User image Patrick Weiden 2014-06-11 02:44:11 PDT
(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 User image Quentin Headen [:qheaden] 2014-06-11 07:35:42 PDT
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 User image Quentin Headen [:qheaden] 2014-06-11 07:43:46 PDT
In addition, the website I am having trouble with is using HTTPS and requires a log in.
Comment 11 User image Kohei Yoshino [:kohei] 2014-06-11 13:05:07 PDT
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 User image Boris Glawe 2014-06-11 14:12:49 PDT
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 User image Kohei Yoshino [:kohei] 2014-06-11 14:22:30 PDT
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 User image Boris Glawe 2014-06-11 14:36:32 PDT
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 User image Kohei Yoshino [:kohei] 2014-06-11 14:40:50 PDT
I'm not affected, but as an OS X user, I'm concerned about this. Follow Bug 828183 for further discussion.
Comment 16 User image Nick Lowe 2014-06-11 19:37:31 PDT
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 User image Nick Lowe 2014-06-12 00:17:00 PDT
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 User image Boris Glawe 2014-06-12 00:57:55 PDT
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 User image Kohei Yoshino [:kohei] 2014-06-12 04:03:53 PDT
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 20 User image Kohei Yoshino [:kohei] 2014-06-12 04:07:45 PDT
*** Bug 1023925 has been marked as a duplicate of this bug. ***
Comment 21 User image :Gijs 2014-06-13 02:11:14 PDT
*** Bug 1024849 has been marked as a duplicate of this bug. ***
Comment 22 User image Sylvestre Ledru [:sylvestre] 2014-06-13 05:03:14 PDT
Since 31 is an ESR, I will probably take a patch for this bug.
Comment 23 User image Patrick McManus [:mcmanus] 2014-06-13 05:13:33 PDT
(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 User image Kohei Yoshino [:kohei] 2014-06-13 12:13:55 PDT
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 User image Lukas Blakk [:lsblakk] use ?needinfo 2014-06-13 12:21:32 PDT
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 User image Lukasz Szybalski 2014-06-19 13:52:24 PDT
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 User image MattyD 2014-06-19 16:25:22 PDT
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 User image Honza Bambas (:mayhemer) 2014-06-21 16:55:00 PDT
Created attachment 8444017 [details] [diff] [review]
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 User image Patrick Weiden 2014-06-22 01:40:50 PDT
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 User image Honza Bambas (:mayhemer) 2014-06-22 17:19:10 PDT
Created attachment 8444176 [details] [diff] [review]
v1.1 [buildable on gcc]
Comment 31 User image Honza Bambas (:mayhemer) 2014-06-23 09:42:44 PDT
(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 User image Jason Duell [:jduell] (needinfo me) 2014-06-23 10:26:57 PDT
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 User image Jason Duell [:jduell] (needinfo me) 2014-06-23 10:29:44 PDT
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 User image Jason Duell [:jduell] (needinfo me) 2014-06-23 10:30:47 PDT
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 User image Honza Bambas (:mayhemer) 2014-06-23 10:31:29 PDT
(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 User image Jason Duell [:jduell] (needinfo me) 2014-06-23 10:44:32 PDT
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 38 User image Honza Bambas (:mayhemer) 2014-06-23 10:46:31 PDT
Comment on attachment 8444556 [details] [diff] [review]
v1.2

See comment 36 for approval request comments.
Comment 39 User image Robert Kaiser 2014-06-23 13:20:33 PDT
(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 User image Sylvestre Ledru [:sylvestre] 2014-06-23 13:24:57 PDT
Yeh, I agree with Kairo, especially if it is indeed low risk.
Comment 41 User image Sylvestre Ledru [:sylvestre] 2014-06-23 13:44:35 PDT
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 43 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-06-23 17:26:19 PDT
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 User image Patrick Weiden 2014-06-23 23:12:02 PDT
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 User image Boris Glawe 2014-06-24 06:25:13 PDT
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 User image Ed Morley [:emorley] 2014-06-24 08:58:40 PDT
https://hg.mozilla.org/mozilla-central/rev/2ca9a20fb91a
Comment 47 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-06-24 12:14:58 PDT
(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 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-06-24 12:18:29 PDT
(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 User image Patrick Weiden 2014-06-24 23:52:38 PDT
(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 User image Patrick Weiden 2014-06-26 06:55:25 PDT
(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 51 User image :Gijs 2014-06-30 05:36:00 PDT
*** Bug 1031913 has been marked as a duplicate of this bug. ***
Comment 52 User image Honza Bambas (:mayhemer) 2014-07-03 05:35:56 PDT
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 53 User image :Gijs 2014-07-04 04:29:44 PDT
*** Bug 1034562 has been marked as a duplicate of this bug. ***
Comment 54 User image Sylvestre Ledru [:sylvestre] 2014-07-18 03:51:24 PDT
Comment on attachment 8444556 [details] [diff] [review]
v1.2

31 is going to ship next week. So, not taking the patch in release.
Comment 55 User image Demian Frederic Mohr 2014-10-08 04:40:07 PDT
*** Bug 1079732 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.