Closed Bug 276827 Opened 20 years ago Closed 20 years ago

Remove Ability to Install Root Certificates

Categories

(Core Graveyard :: Security: UI, enhancement)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: bill+mozilla-bugzilla, Assigned: KaiE)

Details

The typical user does not need to and should not be able to install a new CA Root Certificate as this opens them to man-in-the-middle attacks. It's easy to imagine a phishing expidition that would have a user click and accept the new root before setting up the MIM. Currenty (in Firefox) adding a new Root is a 1 or 2 click operation. There is some corporate need to do this, so perhaps a preference could be added to reenable this feature for the very small subset of users who need it while still protecting the majority of users out of the box.
Assignee: dveditz → kaie
Component: Security: General → Client Library
Product: Core → PSM
Version: Trunk → 2.1
(In reply to comment #0) > The typical user does not need to and should not be able to install a new CA > Root Certificate as this opens them to man-in-the-middle attacks. It's easy to > imagine a phishing expidition that would have a user click and accept the new > root before setting up the MIM. Currenty (in Firefox) adding a new Root is a 1 > or 2 click operation. As I stated on bug 215243 I can't see how this will stop either of the above conditions, very few users would accept a root certificate from a 3rd party because it throws up too many error messages and by default all 3 tick boxes are unticked so the certificates go into the user database disabled by default. MITM attacks are quite difficult to do, especially on an ongoing basis due to the sheer size and scale and interconnecting that occurs across the entire internet. Unless you're stuck in some place that cracks down on civil rights in which case I wouldn't be using PKI in any case. Basically any security will go a long way compared to no security. > There is some corporate need to do this, so perhaps a preference could be added > to reenable this feature for the very small subset of users who need it while > still protecting the majority of users out of the box. I know for a fact there is a lot of companies that use this internally, and the majority of them won't switch from IE because it's currently much easier to do a site wide certificate install using active directory and MS IE.
The basic way this would work is: An e-mail looking 'official', instructs the user that their paypal/ebay/citibank account is going to be deactivated for reason X unless they upgrade their browser security. It says to click 'here'. 'Here' runs a javascript that sniffs for Firefox and gives instructions, with a screenshot even, explaining how to 'upgrade' security. That's the three checkboxes. "OK, that was easy enough," the user thinks, and they present a nice login screen for the user to check his account which hooks to a proxy maybe. The user now has a proper padlock and can check that the certificate really belongs to who it says it is. Or so he thinks. Once the phisher is in, he can repeat this attack with any website at all because there's no check that Citibank's SSL cert is signed by the CA they use, there's only a check that Citibank's SSL cert is signed by any CA. Most users don't know what a certificate is, much less a root certificate. Granted, that's quite unfortunate, but we still let them install a root certifiate with a few clicks. Duane, I understand you want people to be able to easily install the CAcert root certificate, but that same convenience can be a risk. Maybe TPTB will WONTFIX this, but the issue should at least be considered.
(In reply to comment #2) > An e-mail looking 'official', instructs the user that their > paypal/ebay/citibank account is going to be deactivated for reason X unless they phishing scams don't bother now and they manage to get a ton of details about users because they just don't bother checking. I highly doubt they're going to go to all that trouble when they don't need to.
I strongly recommend against this enhancement, first because it is not necessary and second because it would created an unacceptable burden on users. Mozilla Suite (and I suspect the other Mozilla products, too) asks for the user to confirm before installing a new root or intermediate certificate. Even if the certificate is installed, the default is untrusted for all uses. The user must therefore take two actions to install a certificate that can be used to authenticate a secure Web site or verified signed messages: 1. The user must okay the installation. 2. The user must set trust indicators. Newly approved root certificates are automatically included only with newer versions of Mozilla products. Disabling the installation of a root certificate would prevent a user with an older version of a product from picking up newly approved, legitimate certificates listed at <http://www.hecker.org/mozilla/ca-certificate-list/> (as I have done). That would create a disability for such users. Making those users upgrade would create too large a burden when they have no other reason to upgrade.
Importing new root CA certs really is too dangerous for most users. Most users will follow instructions blindly. If the web page says "when it asks you if it's OK, click Yes" and the users will do it. Mozilla now makes it much easier than before for legit CAs to get their certs into the product. Users of old products are vulnerable and need to upgrade. So, I endorse this RFE. But all these opinions, pro and con, are meaningless. PSM is an orphan.
Speaking as an advanced user, but *not* a geek; this is insane. A far better approach would be to offer to look-up the "new" root certificate from a "know-and-generally-considered-reliable" database kept right here at mozilla.org. It could list all generally recognized (like CAcert) and included (like verisign) certificates. Of course CAcert *should* be included, but that argument is going on elsewhere. Lance Haverkamp
I personally disagree with the request to remove the ability. I agree we must support companies that want to "roll their own internal CA". We should not try to increase security by breaking functionality. If you'd like to increase security for the user, I suggest to make it more difficult for the user to import such a CA. Inside the import CA confirmation dialog, we could: - have a short sentence, which explains the user the consequences of trusting a new CA, and that it must be confirmed the other party is really trustworthy - display the CA cert fingerprint, and ask the user to verify it is the one provided by the authority - ask the user to enter some letters contained in the fingerprint Just a few thoughts to make it more difficult and increase awareness. I personally see this "remove CA cert import ability" request as a WONTFIX, but why not change this bug into a "make it more difficult to import root CA certs and increase user awareness" request.
See also bug 267515. It contains the same suggestion to increase user awareness when importing certs.
I really think this is a bad idea. "security though non-implementation" is just as bad as security to obscurity. Yes, a *very naive* user may be tricked into installing a bad CA's cert, but that has to be countered by something better than this RFE. Ignoring for the moment my vested interest in adding CACert and other organisations' certs, what about companies and Universities who have their own local root CAs and who wanted their users to install these certs? If (heaven forbid) this RFE is accepted, I personally would love to contribute in maintaining a fork of Firefox/Mozilla that disables it. Given the lazy person I am, this issues is that important to warrant such an offer from me :) Just like a lot of people have been drilled into not opening attachements from strangers, it should be drilled into them to type in URLs into their browsers and not click on the URL sent via email messages. Strange, when email attachments started propagating viruses, I did not see any call to disable attachment sending capability!
(In reply to comment #7) > I personally disagree with the request to remove the ability. > I agree we must support companies that want to "roll their own internal CA". We do it a our University, and several others also do. In my opinion, my team (systems management) is more trutsworthy assuring a server is located at our network than any CA located outside our bourders that probably has no clue about where or who we are. So our users need to install our CA certificate. > > We should not try to increase security by breaking functionality. Completelly agreed. > > If you'd like to increase security for the user, I suggest to make it more > difficult for the user to import such a CA. That would be a useful approach. > > Inside the import CA confirmation dialog, we could: 8<------8< Excellent proposal. > I personally see this "remove CA cert import ability" request as a WONTFIX, but > why not change this bug into a "make it more difficult to import root CA certs > and increase user awareness" request. > Fully agreed.
At most, the user should be given a very stern warning indicating that choosing to accept a root CA means that they have TOTAL trust in the issuer, AND that the site/email that's offering it is itself not spoofed (the srouce itslef is not already CA endorsed). Example: main corp website chooses to offer their own CA on behalf of subsidiary intranet sites, and has a true CA issued cert and hosts the cert only over an https link. Also of concern when importing a CA -- or even plain signed certs -- is the alt-subject fields, which a malice or just nieve 3rd party CA may sign for, thus being use-able to spoof valid sites. So the certificate-trust dialog should ALWAYS display ALL of the Alt-Subject names + the CN, asking the user of they trust the certifcate supplier to assert the validity of EACH of those domains; 'www.mybank.com' or '*.mybank.com'. Obviously one's own employer shouldnt sign certs (their own or 2nd party requests) that contain unaffiliated 3rd party subject alt names (ala *.yahoo.com), so in this case any newly encountered cert (signed by a user-accepted 3rd party / homebrew CA) should probably also raise a one-time (by cert fingerprint?) dialog asking the user for subject-alt list validation. But I disagree with the idea of disallowing CA imports - too many businesses REQUIRE this to certify huge internal lists of their own machines. Fact is, even a web newbie should know to hit 'no' to a _well worded_ certificate trust warning. And to disable CA trust would be moot in light of a user potentialy accepting self signed certs that have spoofed subject alt names. "The certificate you have just opened is claiming to be an electronic identity validation tool [ala CA], but Mozilla does not have any prior knowledge nor trust of the individual or website who has supplied this file. This could be an attempt to trick you. [CA cert paragraph:] If you choose to accept this certificate for the purposes below [email, www, software checkboxes], you will give its issuer the power to 1) endorse the safety of software that you will run on your computer; 2) to validate digitally-signed email communications, 3) to validate website communcations with financial and other privacy based insitutions. [Non ca cert message, or CA with subject alts:] The certificate claims to be able to positivly identify the follwing websites/emails/software-signing, etc (subject alt fields) Click OK only if: -you are CERTAIN that you trust creator of this file to check the identity and trustworthiness of all of the above identities. -you have VERIFIED that the certificate's fingerprint[s, md5 or sha1] match the ones of its issuer, by dialing "[O goes here]'s" publicly listed telephone number and speaking with someone in the "[OU goes here]" department, or: -you should have recevied this file by hand-delivery from a person you trust. CLICK CANCEL if you do not fully understand the above warning or if you have any doubt whatsoever about the origins of this file" Long winded, could be trimmed, not locale friendly :-), but NECESSARY to limit two forms of spoofing (malice CAs and self signers with wildcards/subject alts)
In light of the effect this could have on CAcert we set out to build our own nss libs with the CAcert root built-in rather then an add-on, on a per user basis to prove 2 things. The first was the feasability if this bug is acted upon and adversly effects CAcert, we wanted an easy option that people could do something to continue including our root certificate in their browser. Secondly the motivation was to prove how much a bad idea this is, in short if a bad guy wanted to get his root certificate into the browser he could simply talk the person into accepting a file download and telling them where to download it to, the net effect is there would be absolutely no error messages, so by making things so hard to include a root certificate there is always an easier back door that can be exploited that makes things worst for security then better.
I am opposed to removing the ability to Import Root Certificates into Firefox. This would deny me the ability to establish my desired WoT. The Libertarian in me rebels at being "forced" to accept "trust" based upon the whims of faceless individuals & organizations. How does this feature even qualify as a "bug?" No one is forced to Import any Root Cert. they do not wish to utilize! JOHN
I'm against disabling installation of a new CA Root Certificate. If it had not been possible in the past to install CA Root Certs, I would have had a hard time in Denmark! We have a government sponsored CA and the certs from that CA is required for internet communication with the official authorities in Denmark. That CA's Root Certificate was not in nss. (TDC OCES that is.) I had to install the Root Certificate on my own. The consequences of not being able to install root certificates would have been a disaster! I think you would find similar examples in the future!
I think we heard enough examples why it's good to have this feature. It helps users. I'm changing this to a WONTFIX. While the point is valid that user awareness should be increased, let's track that in bug 267515.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Product: PSM → Core
I think that this is a very poor decision to not let the end user install their own root certificates - at our University we have self-signed certificates that we use constantly for internal purposes other than financial transactions because we can not afford to pay several hundred dollars for a Verisign, etc. certificate for email, etc. I think that leaving this the way it is, where users can't install their own root certificates will cause people to shy away from Mozilla (I know that I would stay away from it!) As a developer, I already stay away from Mozilla because of the features that are mplemented in IE but aren't supported in Mozilla, and feel that the failure to implement (or the decision to remove) features such as this will cause other people to leave the platform as well. I personally use CACert for my own web development at home, because I also can not afford to pay a few hundred dollars for a certificate. I highly encourage you to reconsider your position on the issue. Thank you very much, Chris Myers, CCNA, A+, Thawte WOT Notary
(In reply to comment #2) > Duane, I understand you want people to be able to easily install the CAcert > root certificate, but that same convenience can be a risk. Maybe TPTB will > WONTFIX this, but the issue should at least be considered. And how would a computer tech add a certification if this gets "fixed" honestly if you dumb down the program you only find a dumber user. I have to walk my clientell through installing darn near any thing. the last thing I want is to not be able to update domain certificates, or my website's certificates so they cannot get to their troubleshooting information/programs. If this were such a great idea microsoft would have already adopted it. they dont for the reason there is alot of software out there that need to be able to have the certificates installable.
If you can find a way to make it so that a "real" certificate from organizations you deem "real" such as Verisign, etc. not cost a buttload of money so that we can actually afford to have 20 of them or however many that are needed, that would be fine. Until that time, don't hamper our ability to use our computers. Right now we're dealing with this issue on Apple computers, because you can't at all visit a secure webpage without a root certificate installed, so since many of our servers use self-generated secure certificates created by the server's CA, users have to go through unencrypted connections to access email, etc. Please don't make us do the same thing on the PC world. By hampering the install of root certificates "for security reasons" you're relegating people to use unencrypted connections, which will cause a much larger security problem. (In reply to comment #17) > (In reply to comment #2) > > Duane, I understand you want people to be able to easily install the CAcert > > root certificate, but that same convenience can be a risk. Maybe TPTB will > > WONTFIX this, but the issue should at least be considered. > And how would a computer tech add a certification if this gets "fixed" > honestly if you dumb down the program you only find a dumber user. I have to > walk my clientell through installing darn near any thing. the last thing I want > is to not be able to update domain certificates, or my website's certificates so > they cannot get to their troubleshooting information/programs. If this were > such a great idea microsoft would have already adopted it. they dont for the > reason there is alot of software out there that need to be able to have the > certificates installable.
(In reply to comment #0) > The typical user does not need to and should not be able to install a new CA > Root Certificate as this opens them to man-in-the-middle attacks. It's easy > to > imagine a phishing expidition that would have a user click and accept the new > root before setting up the MIM. no, its surely not. > Currenty (in Firefox) adding a new Root is a 1 > or 2 click operation. thats a sw-ergonomics and expert-systems problem (just lead the user with the ui and teach him about trust requirements, so this would not happen to him) > > There is some corporate need to do this, so perhaps a preference could be added > to reenable this feature for the very small subset of users who need it while > still protecting the majority of users out of the box. this would ignore the learning curves of users getting more advanced with security certificates. again, this is not about security but ergonomics and expertssystem user support. y tom
(In reply to comment #0) > The typical user does not need to and should not be able to install a new CA > Root Certificate as this opens them to man-in-the-middle attacks. It's easy I agree with the majority of commenters that this is NOT a good idea for the reasons so abundantly stated below. If it somehow must be implemented, make it a toggle under "privacy & security" and unchecked by default.
I filed this bug 4 months ago now, as a devil's-advocate bug around what security decisions we can reasonably ask the user to assume, stemming out of CACert discussions. The response has been resoundingly in favor of trusting the user to manage his own security decisions, which I think is the right approach. The comments not in opposition to this request are around the UI for adding a cert which is being tracked in bug 267515. There was 1 vote in support of this bug. Kai WONTFIX'ed this in February and there hasn't been opposition to the WONTFIX. Marking VERIFIED.
Status: RESOLVED → VERIFIED
I hope you're all aware that presently no one is actively working on PSM. All the PSM bugs are effectively WONTFIX until that situation changes. When it changes, PSM will have a new "module owner". The decisions about which bugs get fixed and which do not are made by the module owner. It's not a democracy. Bug comments are not votes for or against a bug fix. That new owner will be free to revisit any bugs that the previous owner marked WONTFIX. But this is all moot until PSM gets a new owner.
Although I see the author's point, simply removing the user's ability to add a root certificate is not the way to go. Perhaps making it more difficult to do so that a user cannot accidentally setup a MIM situation would be advisable. Most folks will click OK just to make the dialog go away. Having to type a random challenge word and press OK might be a better solution. CAcert.org is a good example of a case where an end user may choose to make an educated decision to add a root certificate. Another case maybe a small company or individual wishing to create their own CA to create a secure web network for his/her friends. It should not be necessary to pay some large company a few hundred dollars simply to obtain a certificate signed by one of the "few" established roots.
(In reply to comment #23) > to go. Perhaps making it more difficult to do so that a user cannot > accidentally setup a MIM situation would be advisable. Most folks will > click OK just to make the dialog go away. Having to type a random > challenge word and press OK might be a better solution. Just clicking OK won't automatically trust a root certificate they must also tick boxes, I'm not sure how much more obvious this could be made without upsetting major companies and universities that rely on the fact they run their own CA or use one that isn't in the root store by default. A lot of universities are promoting firefox etc as an alternative but how long will it take to change if they suddenly have a 10 fold increase support work, or being forced into purchasing certificates at $30+ each, my guess is they wouldn't be promoting people use firefox any more...
Guys, the UI stuff is being tracked over in bug 267515.
this will stop cacert.org Certificates working. this doesnt get my vote
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.