Closed Bug 1314010 Opened 8 years ago Closed 8 years ago

Set security.enterprise_roots.enabled to true by default

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: ayg, Unassigned)

References

Details

Bug 1265113 introduced a preference, security.enterprise_roots.enabled, that causes Firefox to automatically recognize certificates that were added by the administrator to the Windows certificate store.  Currently it is off by default, and to enable it, you have to find out about it and enable it in about:config.  I didn't see any discussion on the bug for why this is, so I wanted to suggest that it be enabled by default.

The use-case for the preference is that some network administrators add certificates to the system store because the need to be trusted for users of that network, e.g., because a proxy intercepts HTTPS connections and re-signs them with a private certificate in order to monitor traffic.  In this case, the affected sites (possibly all HTTPS sites) are broken in Firefox but work in competing browsers, and it is not necessarily even possible to add an exception in Firefox through the UI (e.g., HSTS).  The user and the network administrator probably do not know about the Firefox preference, and the most likely solution is to use another browser.

Is there any reason not to match other browsers and just leave this preference on by default?  What's the downside?  Assuming the cert was installed legitimately, it's probably because the cert must be recognized for HTTPS to work properly on this network.  Are we concerned that malicious filtering programs might install new certs without the user's knowledge, and the user should be alerted to this (assuming they didn't bother updating Firefox's store also)?  Or that the cert was deliberately installed, but the connection might not really be secure (e.g., because the network monitoring proxy might not check the certificates of the actual website properly)?

I would think that the best behavior for now would be to silently recognize these certificates, and not try to police additions to the system certificate store -- that's best done by antivirus software, Windows Update, etc.  If there's a good use-case for alerting the user to suspicious certificates that were added to the system store, some appropriate UI could be devised at a later date, and it should apply to certs that are added to Firefox's own store as well.  If such UI is appropriate, though, I don't think it should block recognizing admin-added certificates by default.

(On a personal note, at some point Firefox stopped working for me because of this issue.  I contacted the maintainer of the relevant proxy for help, and their reply was "use another browser".  Eventually I found this pref and enabled it, and suddenly everything magically works again.)
I agree that this should be the default behavior and would like it to be enabled on a fresh install.
I disagree to activate the feature by default for everyone. If you are an system administrator, you should use MCD to do it. It is most major way to customize default settings globally in managed environments. You just put two files to correct place for each, with any logon script or something.
https://developer.mozilla.org/en-US/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig
I imagine most users do not realize that Firefox installs its own root ca certificates by default. This is very bad since ssl trust is a critical software component. If Mozilla wishes to install a custom certificate trust list, users should be prompted on a fresh installation whether to use system certs, mozilla certs, or support both. I do not believe the decision should be made for them.
Please do not post on this bug about whether Mozilla should use the system certificate list.  Mozilla long ago decided that it will maintain its own certificate list.  If you would like the option to use the system list as-is instead of Mozilla's list (rather than using Mozilla's list plus the administrator's additions), please open a new bug.

(In reply to YUKI "Piro" Hiroshi from comment #2)
> I disagree to activate the feature by default for everyone. If you are an
> system administrator, you should use MCD to do it.

Why do you want to require the user/admin to configure it instead of having it work out of the box?
Sorry, you are right this is the wrong bug and I should not have commented about the system certificate list. Irrespective of my views on that, I think that enterprise certificates should be trusted by default as it is the least surprising behavior and should not require additional customization.
I also suggest that everyone refrain from adding comments saying whether they support or oppose this change.  Instead, please share any *new* points you have, i.e., reasons to enable the pref by default or not that have *not* previously been brought up.  Otherwise it can get very hard to read through the bug, because it gets a lot of comments very quickly.  Thank you!
(In reply to Aryeh Gregor (:ayg) (working until November 1) from comment #4)
> Why do you want to require the user/admin to configure it instead of having
> it work out of the box?

Sorry if I misunderstood your question. Did you mean that why I recommend MCD? Then MCD is just an example way to activate the feature by the system administrator. I think Group Policy Object of Active Directory is better.
This is the sort of feature that requires either an informed buy-in from the user or being enabled as part of a managed environment. We could definitely improve the error pages to detect and suggest when enabling this might be helpful for users, but we're not going to enable it by default for the time being.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Do we require informed user buy-in if a certificate is installed directly in Firefox?  If not, what's the difference?  If installation of the certificate in Firefox is itself considered informed user buy-in, then why is installing it in the system store not?
Flags: needinfo?(dkeeler)
Usually the act of getting the certificate to be trusted by Firefox requires action on behalf of the user (whether it's by installing a specialized add-on or by manually using the certificate manager). I think the difference here is that something may modify the OS certificate store without knowledge of the user. At that point, though, the same mechanism could modify Firefox to trust that same certificate (or even flip this pref), so perhaps the distinction isn't important. That said, because of our focus on the privacy and security of the user, I think it would be best to be able to show some indication when connections aren't being protected by roots in Mozilla's CA program before turning this on by default.
Flags: needinfo?(dkeeler)
All sorts of AV and MITM crap edits the root store on Windows. If they are all also editing our store if we are installed, perhaps there's little value in the distinction, and we should flip the pref by default. But if they aren't, perhaps there is.

Also, before we flip the pref by default, we'd need to work out what happens when certs are trusted by us and untrusted by the platform, or vice versa, and test various combinations to make sure flipping this pref still allows us to keep control of our users security in difficult situations.

Gerv
Certainly plenty of programs install certs in Windows' store but not Firefox's, or else we wouldn't have needed this feature to begin with.  :)  If we don't like new certs being trusted without user approval, the current default setting therefore has an advantage.

So it seems like in theory we'd want to support certs from the root store out of the box, but only with some kind of user approval or at least an indication.  I'm not planning on working on this, so I'll leave the issue here.  Thanks for the explanations.
Per bug 1452070 we know that a significant share of our Windows users also use anti-virus softwares on their machines. From the module ping analysis of 64 bit Windows release users::
- 14.2% have Avast dll loaded in Firefox process
- 3.8% have Kaspersky dll loaded in Firefox process
- 2.8% have ESET dll loaded in Firefox process
- 2.2% have Symantec dll loaded in Firefox process
....

We also know that 3rd party softwares don't always integrate well with Firefox:
- Bug 1449115: Kaspersky issue where “Your connection is not secure" error message is displayed when accessing webpages. Related to installing Kaspersky certificate in Firefox storage
- Bug 1403404: (unresolved yet) issue where 2 users had issues installing Firefox with the stub on Win10 and reported seeing “Your connection is not secure" error message, they were running "Trend Micro" and "Avast" antivirus
- Asa mentioned another instance where we updated the storage format and revved the name of the storage file and it may have taken the AV vendors some time to adjust (that was a few releases back and I'm still seeing reports)

It does not take long for a user to move to another browser if he can't access websites (“Your connection is not secure" error message) and we don't seem to have user friendly opt-in ways to enable security.enterprise_roots.enabled in this situation.
I feel not doing it exposes a large share of our users to mis-configurations from 3rd party softwares that would impact their ability to use Firefox.

Is there a way to test this out using Shield? We could measure user retention and engagement on cohorts where security.enterprise_roots.enabled is set to true or false to validate if it's a better configuration?
Flags: needinfo?(dkeeler)
Barring compatibility issues (and we know of at least one: bug 1427248), setting this to true on Windows will almost certainly result in a configuration where we retain more users. However, as this feature affects the confidentiality of user data, I still think this needs explicit opt-in and hence some sort of UX design.
Flags: needinfo?(dkeeler)
> However, as this feature affects the confidentiality of user data, I still think this needs explicit opt-in and hence some sort of UX design.

Can you provide more detail on what you mean by that?

Anything we do here is still better than what other browsers do (trusting everything).

As long as we hold on to the "if we didn't approve it for inclusion in our cert database, we don't trust it" we're never going to be as compatible as every other browser.

This seems like a reasonable middle ground.
(In reply to Mike Kaply [:mkaply] from comment #15)
> > However, as this feature affects the confidentiality of user data, I still think this needs explicit opt-in and hence some sort of UX design.
> 
> Can you provide more detail on what you mean by that?

I think users will be unpleasantly surprised if we suddenly enable a feature that trusts 3rd party roots if we don't somehow indicate that this has happened.

> Anything we do here is still better than what other browsers do (trusting
> everything).

We could do exactly what other browsers would do, and then we're as bad as them, which isn't a great selling point.

> As long as we hold on to the "if we didn't approve it for inclusion in our
> cert database, we don't trust it" we're never going to be as compatible as
> every other browser.

I think there are more options here. We can design an experience for users that enables them to make an informed decision. For instance, if we detect that a connection is being intercepted, if we can also detect that it's due to a local AV product, maybe we can give the user a message like "Did you know this is happening? If you didn't want this, uninstall or disable the AV. If you did want this to happen, click this button to trust the root." (Or something - I'm not a designer.)
(In reply to David Keeler [:keeler] (use needinfo) from comment #16)
> (In reply to Mike Kaply [:mkaply] from comment #15)
> > > However, as this feature affects the confidentiality of user data, I still think this needs explicit opt-in and hence some sort of UX design.
> > 
> > Can you provide more detail on what you mean by that?
> 
> I think users will be unpleasantly surprised if we suddenly enable a feature
> that trusts 3rd party roots if we don't somehow indicate that this has
> happened.
I know very little about how certs are being managed so excuse me if this is a stupid question but how is "a 3rd party software installs their certificate in Firefox storage" different from "a 3rd party software installs their certificate in the Windows cert store and Firefox picks it up to add it to the Firefox cert store" from a trust standpoint? How is the 2nd scenario less secure than the first one?
Flags: needinfo?(dkeeler)
The difference is the 3rd party software has to deliberately target Firefox (and hopefully they have the user's consent, but often they don't or it's not meaningful, informed consent). For example, the Superfish adware of infamy would add a 3rd party root to the OS trust store. It happened to be the exact same root and key for every install, and since the private key was bundled with the software, anyone who extracted it could intercept the traffic of anyone who had it installed. However, since they didn't add the root to the Firefox root store (and since Firefox didn't automatically import it without notifying the user), Firefox users weren't vulnerable. (And they're not the only ones who have done this - many products, ranging from antivirus to video game clients/updaters have done similar things.)

You're right, though - 3rd party software can (and does) modify the Firefox trust store to include additional roots. Users can as well. One area we're deficient here is informing the user when their traffic is protected by roots in our CA program vs. imported 3rd party roots (I think we have a bug on this but I can't find it right now).
Flags: needinfo?(dkeeler)
See Also: → 1747884
You need to log in before you can comment on or make changes to this bug.