Closed Bug 276827 Opened 20 years ago Closed 19 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: 19 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.