Closed Bug 1023748 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: Networking, defect)

30 Branch
x86
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla33
Tracking Status
firefox30 - wontfix
firefox31 + verified
firefox32 + fixed
firefox33 --- fixed

People

(Reporter: public, Assigned: mayhemer)

References

Details

(Keywords: dev-doc-needed, regression, site-compat, Whiteboard: [qa-])

Attachments

(1 file, 2 obsolete files)

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.
I have to mention: It works perfectly with Firefox version 30.0 for Windows 7.
... and it worked perfectly with MAC until the update to version 30.0, yesterday.
... and we are using Sharepoint 2010.

Alle installed addons are deactivated but it still doesn't work.
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.
Hi Patrick,

the login popup does not appear.

I agree, that this might be the correct path to the source of our problem.
The site is a https site with an officially signed (not self signed) certificate. Firefox does not report any problems with the certificate.
Same issue with Firefox 30.0 for Android.
(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.
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.
In addition, the website I am having trouble with is using HTTPS and requires a log in.
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
Blocks: 828183
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.
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
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?
I'm not affected, but as an OS X user, I'm concerned about this. Follow Bug 828183 for further discussion.
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.
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.)
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
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
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
Product: Firefox → Core
Summary: Firefox 30.0 for Mac shows sharepoint sites as empty pages → Allow NTLMv1 over SSL/TLS, or intranet access is broken on Firefox 30 for non-Windows platforms
Severity: normal → major
Since 31 is an ESR, I will probably take a patch for this bug.
(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 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.
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.
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
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.
Attached patch v1 (obsolete) — Splinter Review
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|.
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Attachment #8444017 - Flags: review?(jduell.mcbugs)
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
Attached patch v1.1 [buildable on gcc] (obsolete) — Splinter Review
(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 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.
Attachment #8444017 - Flags: review?(jduell.mcbugs) → review+
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.
Attachment #8444017 - Flags: review+ → review-
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)
Attachment #8444176 - Flags: review+
(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.
Attachment #8444017 - Attachment is obsolete: true
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.
Attachment #8444176 - Flags: approval-mozilla-release?
Attachment #8444176 - Flags: approval-mozilla-beta?
Attachment #8444176 - Flags: approval-mozilla-aurora?
Attached patch v1.2Splinter Review
https://hg.mozilla.org/integration/mozilla-inbound/rev/2ca9a20fb91a
Attachment #8444176 - Attachment is obsolete: true
Attachment #8444176 - Flags: approval-mozilla-release?
Attachment #8444176 - Flags: approval-mozilla-beta?
Attachment #8444176 - Flags: approval-mozilla-aurora?
Attachment #8444556 - Flags: review+
Comment on attachment 8444556 [details] [diff] [review]
v1.2

See comment 36 for approval request comments.
Attachment #8444556 - Flags: approval-mozilla-release?
Attachment #8444556 - Flags: approval-mozilla-beta?
Attachment #8444556 - Flags: approval-mozilla-aurora?
(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.
Yeh, I agree with Kairo, especially if it is indeed low risk.
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.
Attachment #8444556 - Flags: approval-mozilla-beta?
Attachment #8444556 - Flags: approval-mozilla-beta+
Attachment #8444556 - Flags: approval-mozilla-aurora?
Attachment #8444556 - Flags: approval-mozilla-aurora+
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/
Flags: needinfo?(public)
Whiteboard: [qa-]
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
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.
Flags: needinfo?(public)
https://hg.mozilla.org/mozilla-central/rev/2ca9a20fb91a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
(In reply to Boris Glawe from comment #45)
> It works perfectly! Thanks! I'm looking forward to the firefox 31.0.

Thanks Boris!
(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.
(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.
Depends on: 1030426
(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).
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 on attachment 8444556 [details] [diff] [review]
v1.2

31 is going to ship next week. So, not taking the patch in release.
Attachment #8444556 - Flags: approval-mozilla-release? → approval-mozilla-release-
You need to log in before you can comment on or make changes to this bug.