292824 - Certificate management should be cryptographically secured

Status: RESOLVED EXPIRED

(SeaMonkey :: Security, enhancement)

Description

[Ulrich Windl]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414

I made a mistake: I read a book about PKI (Public Key Infrastructure) ;-)

Most users when using TLS or SSL (HTTPS) seems to be happy to know that their
data is sent encrypted to some remote endpoint. However, TLS gives you more:
Know whom you are talking to. The latter is implemented through X509 certificates.

Currently the common browsers come with several "trusted" CA certificates
presinstalled. The user may add, modify, or remove those "trusted" certificates.
Trust in any certificate is automatically deduced from the base of installed
"trusted" CA certificates. (Note that I'm using quotation marks around "trusted")

Now imagine a two-step visrus does the following:
Step 1: Import a new CA-Certificate of questionable reputation via some trojan
to your "trust base"
Step 2: Some Program convinces you to visit a HTTPS protected site (a forgery)
to send precious private information (like passwords or credit card numbers)

The browser will fully trust the dubious site's certificate as there is a bogus
trusted CA imported to your "trusted CA base".

If that sounds too far away for you, imagine: <[e-mail]>
who is responsible for software installation in a big company has produced an
applet of dubious security (ability to withstand attacks). To avaoid any
application warnings, he signs his applet with his self-signed certificate,
which, in turn. he automatically distributes on PCs in the company.

No user will notice that his browser has a new, dubious trustworthy certificate.

IMHO trust is a matter of personal decision, thus the "trusted base" should be
protected at the same level as the password manager (what about the form
manager?) protects its data. So if the user chose to protect the passwords via a
"master password" (security device), data of similar sensitivity should be
protected similarly. If not encryping the certificate storage, a digital
signature (hash) should be at least stored to the security device to recognize
tampering of the certificate storage.
I know that there are still enough possible attacks (like installing a modified
trojan browser that will always find itself uncorrupted), but increasing
protection of sensitive data seems important to me.

Reproducible: Always

Steps to Reproduce:
See lengthy description.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.