Is NSSCKBI.DLL safe?
Nobody
(http://www.privsoft.com/archive/nws-who.html), PSC software (BOClean)
indicated that they believe that NSSCKBI.DLL contains some questionable
and demonstratively untrustworthy certificate authorities. Their
initial reaction was to include the file in their definitions and offer
to remove it. After complaints that this was a false positive and after
finding that removing the file broke Mozilla products, they removed
NSSCKBI.DLL from their definitions, reissued the update, and published
their newsletter explaining the course of events. They continue to
believe that the file (or rather some of the CAs in the file) is
untrustworthy but don't want to break FF.
Many of us rely heavily on FFs indication that a site is safe before we
enter personal or financial info. Please comment on whether you
consider PSCs concerns reasonable, and if so, whether an effort will be
make to remedy this problem.
F/Us set to mozilla.dev.security
Frank Wein
The URL above gets so many things wrong, lets look at a few.
> Mozilla's NSSCKBI.DLL file contains a number of "secure sockets layer" (SSL) certificates, including certificates from several unknown and possibly dubious "certifying authorities."
mozilla.org has a Certificate Policy which states which CA certificates
can get in, you can find it under
https://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html.
Almost all (I'm not sure if the very old ones were checked) the CAs
which are included were checked if they fulfill those requirements. In
the QuoVadis case which they mentioned they could have looked that info
up under https://bugzilla.mozilla.org/show_bug.cgi?id=261375 and in
netscape.public.mozilla.crypto.
> The "issue" as we see it is that the end user is not presented with the ability to accept or decline certificates by these unknown quantities, and once a certificate is "stored" on the machine, then any certificate granted by these authorities to others is now considered both "valid" and "safe." Further, the option to VIEW the existing certificates is not available to the user through Netscape/Mozilla/Firefox and is instead hidden in the Windows registry in a difficult to view and modify means.
Also wrong, there is a certificate manager included in both Mozilla and
Firefox (check in Preferences window), where you can view all stored
certificates and delete them if you want. The certificates are stored in
the user profile, not in the registry.
> The "root certificates" which this file places go into the Windows registry in the following key:
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
>
> and exists as "subkeys" of the above with GUID numbers to identify each subkey. Names are not used. The data for the various root authorities is unfortunately coded as "binary" rather than text, making viewing of the contents challenging, and no "viewer/editor" within Netscape/mozilla/Firefox is apparently available for their contents.
I'm not to 100% sure here (I do not deal with the NSS/SSL part of
Mozilla that often), but I'm quite sure that nssckbi.dll has _nothing_
to do with this registry key. I doubt NSS writes anything to that
registry key. I still don't know how they did come to the conclusion NSS
has modified that registry key.
> And "tinderbox" in the official name for this code is highly unfortunate too
A quick Google search would have told them what this is :) (#4 on Google).
I did not address all the errors on that page, but at least some and I
hope some things are a bit more clear now...
Frank
Julien Pierre
Is this somebody's idea of a joke ?
This site makes a lot of unsubstantiated and bogus allegations .
I am only responding to show how little the author knows about Mozilla.
Quote :
"c:\builds\tinderbox\Fx-Mozilla1.8.0-Release\WINNT_5.2_Depend\mozilla\nss\nssckbi\nssckbi.pdb
**********************************************************/
The "root certificates" which this file places go into the Windows
registry in the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
and exists as "subkeys" of the above with GUID numbers to identify each
subkey."
This is a PDB file - a Microsoft Program Database file - in other word,
debug information. This file doesn't contain any code, and thus cannot
place any certs into the registry, by definition.
The writer probably meant to discuss nssckbi.dll, which is a PKCS#11
module containing the definitions of the root certs used in Mozilla.
This module also does not touch the Windows registry.
The discussion that follows is based on this incorrect statement.
Quote :
"no "viewer/editor" within Netscape/mozilla/Firefox is apparently
available for their contents"
The author must not have looked very hard. In Mozilla suite or
SeaMonkey, go to Edit/Preferences/Privacy & Security/Certificates/Manage
Certificates/Authorities. Click on "View" and "Edit" buttons.
All the certs from nssckbi.dll are from the "Built-in Object Token" and
viewable and editable.
Quote :
"Mozilla's NSSCKBI.DLL file contains a number of "secure sockets layer"
(SSL) certificates, including certificates from several unknown and
possibly dubious "certifying authorities." It is our opinion that there
are some questions raised by the presence of this module and in
particular its contents and its ability to modify the machines of users
of Netscape, Mozilla and Firefox. Therefore, we hope some external and
independent parties and other experts might examine this further,
independent of us, to determine whether there actually is a concern here.
...
We feel that this is a serious security risk since some of the
"certifying authorities" embedded in this file are known to be used by a
number of malware programs and because any download "signed" by any of
these questionable certifying authorities would be downloaded, installed
and run without warning because of the successfully "signed
certificate." This is the crux of the issue as we see it, but disabling
this file completely breaks Netscape/Mozilla/Firefox (as well as the
winsock stack) as was reported when we learned of the "false positive."
We had no choice but to immediately pull the "detection" as a result and
assist a number of users ill-affected in restoring the "status quo" who
had not received the update which resolved the problem."
How about substantiating this claim and stating which CAs are known to
be used by malware programs ? If true, this information would be of
great interest to the Mozilla foundation to remove such certificates.
Note that most CAs in nssckbi.dll have already gone through evaluations,
either by Netscape before the browser code was open sourced, or by
Webtrust subsequently.
Quote :
"The "issue" as we see it is that the end user is not presented with the
ability to accept or decline certificates by these unknown quantities,
and once a certificate is "stored" on the machine, then any certificate
granted by these authorities to others is now considered both "valid"
and "safe." Further, the option to VIEW the existing certificates is not
available to the user through Netscape/Mozilla/Firefox and is instead
hidden in the Windows registry in a difficult to view and modify means."
Mozilla does not in any way rely on the Windows registry for certificate
storage or trust. It uses the PKCS#11 interface. I'll refer you to my
earlier answer about how to view and editing certificates in Mozilla.
oops199
into any of the esoteric questions raised, perhaps it would be a VERY
good idea to take a look at the real issue.
That issue would seem to be that FireFox comes "out of the download"
with some fairly questionable sites automatically setup as acceptable
security certificate issuers. This is a real problem. Many users, in
fact most users, have no idea what the certif's are or who should be
issuing and verifying them. Additionally we have all seen recently
ways that unscrupulous ones have managed to get apparently valid
certifs. Cerif's are a real problem and NOT one that an average user
should be expected to handle.
So let's see some immediate action by Mozilla // FF to correct this
problem. If FF is not willing to deal with the certif problem better,
then there needs to be a third party, like the folks ot SpywareBlaster,
take on the issue of providing info on valid trustworthy certif
issuers. In any case FF needs to put this situation up front to the
user. And notclaim to have "handled" it by "tools options.... "
And is this not just another example of the flawed philosophy of "push"
vs pull. Users are far better off when such well thought of programs
like FF do not come "out of the download" ready to bite users. It
seems that by automatically facilitating certifs from less than totally
upfront sites, FF has left its users just ready for being con'd.
disappointed
Oops199
Frank Hecker
<snip>
> This site makes a lot of unsubstantiated and bogus allegations .
> I am only responding to show how little the author knows about Mozilla.
Julien, thanks for responding to this.
Here's my own summary of the situation, in response to the material
published in the Privacy Software Corporation Newsletter dated July 24,
2006:
1. The file NSSCKBI.DLL mentioned in the PSC newsletter contains the
pre-loaded root CA certificate list shipped with Mozilla-based products,
including Firefox, Thunderbird, Mozilla Suite, Seamonkey, and Camino. It
is part of the Network Security Services (NSS) cryptographic library
that provides SSL and other support for Mozilla-based products.
NSSCKBI.DLL contains only the root CA certificate data; it does not
actually perform any certificate-related operations.
2. The Windows registry key referenced by the PSC newsletter:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
is associated with Microsoft Windows, and contains data associated with
pre-loaded root CA certificates used by Internet Explorer and other
Windows applications.
This registry key has nothing to do with Mozilla-based products, NSS, or
NSSCKBI.DLL. NSS and other Mozilla code do not use this key or write to
it; as noted above NSS stores pre-loaded root CA certificate data in
NSSCKBI.DLL.
Other parts of the Mozilla code do read and write the Windows registry,
but they do so in a separate section of the registry, under
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\...
3. Contrary to the assertion in the PSC newsletter, the root CA
certificates used by Mozilla-based products (including the certificates
stored in NSSCKBI.DLL) can be viewed and edited from within the
preferences dialogs of those various products. For example, with Firefox
1.5 Under Windows the user can view and edit certificate data as follows:
1. From the "Tools" menu, select the "Options..." menu item.
2. In the resulting dialog box, click on the "Advanced" toolbar
button.
3. Select the "Security" tab.
4. Click on the "View Certificates" button.
5. In the resulting dialog box, select the "Authorities" tab.
6. Click on a CA certificate to select it.
7. Click on the "View" button to view the certificate and related
information, on the "Edit" button to modify settings for the
CA and its certificate, and on the "Delete" button to delete
the certificate.
Other Mozilla-based products have similar features.
Note that "deleting" a pre-loaded CA certificate doesn't actually delete
it from the file NSSCKBI.DLL, but rather disables use of that CA and its
certificate within the Mozilla-based product in question.
4. Although it's not relevant to Mozilla (as discussed above), note that
(contrary to the assertion of the PSC newsletter) the pre-loaded set of
CA certificates for Microsoft Windows as stored in the registry key
mentioned above can in fact be viewed and edited as well. For Windows XP
and Internet Explorer 6, the steps are as follows:
1. From the "Tools" menu select the "Internet Options..." menu item.
2. In the resulting dialog box select the "Content" tab.
3. Click on either the "Certificates" button (for CA certificates
related to SSL) or the "Publishers" button (for CA certificates
related to ActiveX code signing).
4. In the resulting dialog box select the "Trusted Root Certification
Authorities" tab.
5. Click on a CA certificate to select it.
6. Click on the "View" button to view the certificate and related
information, on the "Advanced" button to modify settings for the
CA and its certificate, and on the "Remove" button to delete
the certificate.
5. The Mozilla Foundation selects CA certificates for pre-loading into
Mozilla-based products based on its policy as described at
https://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html
As part of this policy we evaluate the benefits and risks of including a
particular CA's certificate in our pre-loaded list, including looking at
independent evaluations of the CA in question. For CAs included since
the policy was officially adopted, we maintain in the Mozilla project's
Bugzilla bug database a public record of discussions related to the
decision to include or not include a particular CA; see
http://www.hecker.org/mozilla/ca-certificate-list
for references to such records (in the "Related Bugs" column).
If anyone, including PSC, has reason to believe that including a
particular CA's certificate poses a security risk to users of
Mozilla-based products then they are free to submit a bug report
providing evidence to that effect and we'll look into it. Such reports
can be submitted directly into the Mozilla bug database at
<http://bugzilla.mozilla.org/> or can be sent to the email address
secu...@mozilla.org.
Again, though it's not directly relevant to Mozilla-based products,
other browser vendors (e.g., Microsoft, Apple, Opera, etc.) maintain
similar pre-loaded CA certificate lists and have similar policies
related to including new CA certificates in the list. Note that there is
substantial (though not 100%) overlap between the various lists; for
example, the Thawte, USERtrust, and Quo Vadis CAs mentioned in the PSC
newsletter are in both the Mozilla list and the Windows list.
I hope this answers the questions raised by the PSC newsletter. If
anyone has any further questions please feel free to post in this forum
or email me directly.
Frank
--
Frank Hecker
Executive Director
hec...@mozillafoundation.org
Frank Hecker
> Two posters have taken issue with the BOClean item. Without getting
> into any of the esoteric questions raised, perhaps it would be a VERY
> good idea to take a look at the real issue.
>
> That issue would seem to be that FireFox comes "out of the download"
> with some fairly questionable sites automatically setup as acceptable
> security certificate issuers. This is a real problem. Many users, in
> fact most users, have no idea what the certif's are or who should be
> issuing and verifying them. Additionally we have all seen recently
> ways that unscrupulous ones have managed to get apparently valid
> certifs. Cerif's are a real problem and NOT one that an average user
> should be expected to handle.
>
> So let's see some immediate action by Mozilla // FF to correct this
> problem.
As noted in a message I just sent to this forum, the Mozilla project in
general (and the Mozilla Foundation in particular) have in fact been
dealing with the CA certificate issue for quite some time now. We have
an official policy on how we decide to include CAs or not (a policy that
was created through a public process with lots of discussion from lots
of people), a public process by which we go about making a decision on a
particular CA (with a public record kept in our Bugzilla bug database),
and a defined process by which people can submit reports of security
vulnerabilities, including any vulnerabilities related to the CA
certificates we pre-load.
If you or anyone else thinks there are security problems with a
particular CA, please file a bug in Bugzilla or send a message to
secu...@mozilla.org, along with *specific* evidence of the problem and
the resulting threat to users. Please also include any evidence related
to what the CA has or hasn't done.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
srdav...@gmail.com
their withdrawn signature (QuoVadis being only one of the dozens of CAs
represented in the root store).
QuoVadis is a reputable CA located in Bermuda and with operations in
Swtizerland and New Zealand. In addition to Mozilla, its root is
distributed in Windows, Apple, RIM/Blackberry, and others. Among its
various security accreditations, the company holds a Webtrust for CAs
seal (conducted by Ernst & Young) as well as an ETSI TS 101.456
certification (conducted by KPMG as part of its licensing as a
Qualified Service Provider in Europe).
The unfortunate mistakes made by PSC would have been avoided through
basic research about Mozilla and certification authorities. Any
imputation by PSC of "dubious CAs" should be backed up by concrete
evidence rather than libellous hyperbole.
Mele
comes back and appears FULLY FUNCTIONAL rather than being disabled. So, I
don't understand your statement.
I would like to ask why are there root certs for Fx that cannot be verified
because, according to Fx, the issuer is NOT trusted? It makes me nervous
having certs that cannot be verified and that, when deleted, promptly return
to the list and appear functional. Those certs are not even on the list that
is on your web page. I assume they are legacy certs but why are certs that
cannot be verified there at all? I am referring to beTRUSTed Root CCA
Baltimore Implementation, beTRUSTEed Root CA RSA Implementation, and
beTRUSTed Root CA Entrust Implementation.
I am unable to delete the GTE CyberTrust Root CA that expired in February.
That one also comes back. Why? I also deleted the GoDaddy cert and it comes
back. If these are actually disabled then why are they back in the list and
not at least grayed out or have "disabled" beside them? Should I not be
informed that they are disabled if they truly are?
I have another question regarding Fx certs that is not directly related to
PSC's findings but would like to ask it. Why does Fx not have any certs from
Microsoft? It is very irritating every time I go to a secure Microsoft site
on Fx to have Fx tell me that the certificate cannot be trusted (Microsoft
Secure Server Authority which is an intermediate cert). Along these lines,
I also would like to know why Fx jumbles up the intermediate and root certs
all on one tab? They should be on separate tabs.
"Frank Hecker" <hec...@mozillafoundation.org> wrote in message
news:44C69B78...@mozillafoundation.org...
Frank Hecker
> I have tried to delete a root cert from Fx and have found that the cert
> comes back and appears FULLY FUNCTIONAL rather than being disabled. So, I
> don't understand your statement.
Actually I saw your post elsewhere and decided to check this out. Here's
what I observed (using Firefox 1.5.0.4 on Windows XP SP2):
1. I started with a root CA certificate that was pre-loaded and marked
as trusted for all uses (in my case the ABA.ECOM root CA). (I verified
this using the "Edit" button.)
2. I then used the "Delete" button to attempt to delete the root CA
certificate that was pre-loaded . The operation attempted to succeed and
the root CA cert disappeared from the displayed list.
3. I then exited Firefox, restarted it, and went back to the root CA
list. The root CA certificate I had "deleted" was still in the displayed
list of root certs, but when I checked using "Edit" it was *not* marked
as trusted for any purpose.
Background: Pre-loaded root CA certs in NSSCIBK.DLL can't really be
deleted from that file, because it's a read-only shared library that is
separate from the modifiable Mozilla certificate database. I haven't
verified this, but I suspect that root CA certs in the modifiable
database (which is populated by the user) can in fact be deleted "for
real", but root CA certs in NSSCKBI.DLL can only be marked as untrusted.
From a security point of view the effect is the same -- any
certificates issued under the "deleted" CA are no longer recognized as
valid -- but I agree that this is confusing from a UI point of view.
I've filed a bug about this against the PSM component of Firefox (the
component that I think is handing the UI for this):
https://bugzilla.mozilla.org/show_bug.cgi?id=345934
> I would like to ask why are there root certs for Fx that cannot be verified
> because, according to Fx, the issuer is NOT trusted?
To my knowledge no root CA certs shipped pre-loaded with Firefox (and
other Mozilla-based products) are marked as untrusted "out of the box".
However it is certainly possible for a user to explicitly mark a root
cert as not trusted; this can be done for both pre-loaded root CA certs
and for root CA certs that the user might have later downloaded into
Firefox and marked as trusted on their own.
> It makes me nervous
> having certs that cannot be verified and that, when deleted, promptly return
> to the list and appear functional. Those certs are not even on the list that
> is on your web page. I assume they are legacy certs
That is correct. The list on my web page covers only CA certs that were
added since the Mozilla Foundation took over the task of selecting new
CAs to be added. There's currently a bug filed relating to creating an
official page that lists all pre-loaded CA certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=333272
> but why are certs that
> cannot be verified there at all? I am referring to beTRUSTed Root CCA
> Baltimore Implementation, beTRUSTEed Root CA RSA Implementation, and
> beTRUSTed Root CA Entrust Implementation.
In my vanilla installation of Firefox all of the beTRUSTed root CA certs
are marked as trusted. If they are not marked as trusted in your copy of
Firefox I suspect that it's because you attempted to delete the
beTRUSTed CA certs in the past, with results as I describe above.
> I am unable to delete the GTE CyberTrust Root CA that expired in February.
> That one also comes back. Why? I also deleted the GoDaddy cert and it comes
> back.
These CA certs are also in NSSCKBI.DLL and hence cannot be deleted "for
real", but only marked as untrusted.
> If these are actually disabled then why are they back in the list and
> not at least grayed out or have "disabled" beside them? Should I not be
> informed that they are disabled if they truly are?
I agree that this is confusing behavior, which is why I filed a bug
report about it as noted above.
> I have another question regarding Fx certs that is not directly related to
> PSC's findings but would like to ask it. Why does Fx not have any certs from
> Microsoft? It is very irritating every time I go to a secure Microsoft site
> on Fx to have Fx tell me that the certificate cannot be trusted (Microsoft
> Secure Server Authority which is an intermediate cert).
Can you give an example of such a site, so we can try it out? Also, note
that we don't pre-load intermediate CA certs, only root CA certs, so if
the Microsoft CA in question is an intermediate CA then we would not
pre-load it, but instead would have to pre-load whatever root CA cert it
was ultimately issued from.
> Along these lines,
> I also would like to know why Fx jumbles up the intermediate and root certs
> all on one tab? They should be on separate tabs.
As mentioned above, as a matter of policy we don't pre-load intermediate
certs, only root CA certs, so as installed "out of the box" the Firefox
CA cert list will contain only root CA certs. Also, unlike Internet
Explorer, Firefox does *not* cache and store intermediate CA certs that
it encounters in the course of doing SSL connections and the like.
As a result the only intermediate CA certs that might end up in the
Firefox cert database are those that are explicitly added by the user.
This is a relatively uncommon thing, which may be why we don't split
intermediate CAs out as a separate list in the Firefox UI. However I'm
not really the expert on this particular aspect of Firefox, so I'll
defer to others more knowledgeable than I.
Frank Hecker
> 2. I then used the "Delete" button to attempt to delete the root CA
> certificate that was pre-loaded . The operation attempted to succeed and
> the root CA cert disappeared from the displayed list.
Sorry, I meant to write "The operation appeared to succeed..."
oops199
interesting. First he stalwardly defends FF. Then he acknowledges
that much of what was reported and commented on is in fact not wrong.
And now he begs off as not being an expert.
Not ragging you, Frank. Just pointing out the irony of an aggressive
defense that does not stand up under scrutiny. So please lets get a
Mozilla Security expert in here.
Originally I got interested in this as a result of a post in the GRC
newsgroups. And I was reluctant to believe that my favorite browser
came "preloaded to trust" certifs from sites that have been publishing
improperly attributed certs and ones that are pretty much unheard of.
Now I am glad I did. This needs some additional review. If FF lets
you "delete" an item and then puts it back...??? well certainly makes
sense and we can be sure every user will spend lots of time assuring
that the delete was deleted.
So can we get a discussion of how this relates to improving phishing.
So that the next time I go to my bank and end up at "check free", I can
beleive the cert that is the ssl from my own bank??? Sounds like the
pathway here is muddled enough so as to be way too exploitable. So
regardles of the proceeedure that seems to be referenced as a defense
for including the listed root certs, the results are munged and users
stuck with "push".
more disappointed
oops199
Frank Hecker
> Well now based on what Frank Hecker has posted, this is really getting
> interesting. First he stalwardly defends FF. Then he acknowledges
> that much of what was reported and commented on is in fact not wrong.
> And now he begs off as not being an expert.
I'm sorry, I don't understand your point here: Where exactly did I
"[acknowledge] that much of what was reported and commented on is in
fact not wrong"?
Of PSC's various claims (that NSSCKBI.DLL was malware, that
Mozilla/Firefox stored its certificates in the Windows registry, that
Mozilla/Firefox provided no way to view/edit/delete certificates, etc.)
most if not all are either wrong or at best misleading.
Mele's claims about Firefox behavior in deleting certs do in fact have
some validity, at least in terms of the UI issues, which is why I filed
a bug report about it. However as I noted, although the current Firefox
behavior may confuse users it does not in fact adversely affect their
security -- if a user "deletes" a pre-loaded CA cert in Firefox that
cert is indeed deactivated from use, even though it still shows up in
the list.
Other than that one issue I don't see much if anything where I'm
"[acknowledging] that much of what was reported and commented on is in
fact not wrong".
> Not ragging you, Frank. Just pointing out the irony of an aggressive
> defense that does not stand up under scrutiny. So please lets get a
> Mozilla Security expert in here.
Hey, I'm not proud. If I've written anything that's incorrect then I'd
be glad to accept correction from any of the Mozilla crypto/security
developers reading this newsgroup.
> Originally I got interested in this as a result of a post in the GRC
> newsgroups. And I was reluctant to believe that my favorite browser
> came "preloaded to trust" certifs from sites that have been publishing
> improperly attributed certs and ones that are pretty much unheard of.
> Now I am glad I did. This needs some additional review.
As I wrote earlier, we've been reviewing CAs for several years now. If
you or anyone else has a specific complaint about a specific CA, and you
can back it up with specific evidence, then we're happy to look into it.
Regarding CAs that in your opinion "are pretty much unheard of", there
are lots of CAs in the world beyond Verisign, Thawte, etc. This is
especially true outside the US, and we ship Firefox worldwide, with a
single worldwide pre-loaded root CA list. Many of the CAs that you're
unfamiliar with are in fact well-known in particular countries and
regions, and are perfectly legitimate CAs.
Regarding the claims about CAs "publishing improperly attributed certs",
again some specific facts would be welcome: which CAs? which certs? and
so on. Also, I'm not sure what you mean by "improperly attributed
certs": Do you mean certs issued to someone who falsely claimed to be
someone else? (For example, if a spyware author claimed to be Microsoft
and got issued an ActiveX code signing cert.) Or do you mean certs
issued to someone who then proceeded to do bad things? (For example, if
a company got a code signing cert and then used it to sign malware.)
The former problem (issuing certs to imposters) is in fact something CAs
are supposed to prevent through their procedures. If for some reason the
procedures don't work and something slips through then CAs are supposed
to address the problem by revoking the certificate. If particular CAs
are consistently doing a poor job on both the front end vetting of
applications and the back end revocation of bad certs then we'd
certainly want to re-look at that CA. But, again, mere allegations
aren't enough; we have to have some real evidence.
The latter problem (people getting certs and then doing bad things) is
something CAs can't necessarily prevent on the front end (because the
person or company getting the cert may not have done anything fraudulent
yet), but could address on the back end by revoking certificates. Again,
if you or anyone has evidence that a particular CA is falling down on
the job here then we'd be glad to consider it.
> If FF lets
> you "delete" an item and then puts it back...??? well certainly makes
> sense and we can be sure every user will spend lots of time assuring
> that the delete was deleted.
As I wrote in my previous message, the UI around "deleting" pre-loaded
certificates should definitely be changed to make it clearer what's
going on.
> So can we get a discussion of how this relates to improving phishing.
> So that the next time I go to my bank and end up at "check free", I can
> beleive the cert that is the ssl from my own bank??? Sounds like the
> pathway here is muddled enough so as to be way too exploitable.
I'm unclear on what you're referring to here. Are you referring to the
issue where some banks redirect you from their own site (e.g.,
"bank.com") to another site (e.g., "checking.com")? I agree that this
can cause confusion for users, however that's a problem that the banks
themselves caused and are responsible for; I'm not sure what Firefox
could do to address this issue.
> So
> regardles of the proceeedure that seems to be referenced as a defense
> for including the listed root certs, the results are munged and users
> stuck with "push".
I'm sorry, I'm not exactly sure what you meant by this last sentence. In
any case, certificates and CAs are *not* in and of themselves a defense
against phishing and related online fraud. At best a CA verifies the
identity of a site's operator, or at least confirms that the site
operator owns and controls the domain in question. However CAs don't in
any way verify that the people getting certificates are legitimate
businesses. It's perfectly possible for phishers, scammers, etc., to get
certificates for their sites.
oops199
Thanks for your reply. Presently am just too tired to do your answer
justice. perhaps tomorrow.
The generality to which I refer "push" is a basic philosophy that seems
to pervade an awful lot if not all the net today. Specifically, by not
making the installed certs both more evident to the user and by not
making them fully removable by users, FF is "doing what is best" for
?the users? or for site publishers? Perhaps today our browsers just
may be trying to do too much and do not allow the user to effectively
block "unneeded" frills. A summary on that would be that most of us
block all flash and view sites that rely on flash as both security
risks (5 flash vulns in last 6 months) and unnecessary marketting hype.
Yet sites often continue to both throw flash and to demand javascript
where neither are necessary, cute but not necessary.
regarding the cert problems: The answer to your which one question is
"yes both". As far as specifci examples, I do not track that and have
no desire to do so. As a somewhat tech user, I expect experts to do
that and I would refer you to at least three entries in the SANS diary
over the last 6 months on failures to revoke known fraud certs (both
Twaite and Verisign I believe), failure to verify the cert applicant
before issuing a cert, and as pointed out above one of the root certs
has apparently expired. So are you saying that FF has fully proofed
the root certs? If not, then the following of a proceedure did not
seem to have eliminated questionablly operated root certs.
But you are right with the changes you are proposing (bug reports), the
situation should be improved a bit. Certs are a problem. And like the
banking redirects to "checks.x" improper implementations can lead to a
whole other set of problems. I would suggest on "features" like certs
and other more controversial items (like that FF ping home thing from
months ago) that it would serve FF better to make the user more an
active part on the installation of such.
sleepy & tired
Oops199
Nelson B
I added the Quo Vadis CA certificate to it (per Frank's request).
Thanks to open source, that's an easily verifiable public fact. Look at
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ckfw/builtins/certdata.txt&rev=1.39#10411
Click on my name on that line for more.
So I know a thing or two about this subject.
There's a LOT of misinformation being spread and I intend to address
much of it in this thread (but not all in this message).
People who issue certificates are "cert issuers" or "certification
authorities" or just "CAs". CA certs that come from other CAs are
called "intermediate" or "subordinate" CA certs. CA certs that come
from no-one else, and are their own final authority, are called
"root CA" certs, or (rarely) "trust anchors".
Point 1: CAs vouch for identity, not for character or reputation.
CA's issue certs. Certs are signed documents that say, in effect
"I certificate that this public key belongs to the party named herein
and is valid for these uses ..."
Certs do NOT say "I certify that the party named herein is reputable,
honest, loyal, brave, trustworthy, a good businessman, a good developer,
will give you your money back if you're unsatisfied" or anything like that.
Certs say: "Here's the name of the party who has this key."
The implication is:
if you have trouble with the party named in this cert, at least you have
the party's name and can hold that party responsible for his actions.
If a party to whom a cert is issued acts in bad faith, that is not in
itself a bad reflection on the CA that issued the cert. If the information
in the cert is falsified, and the CA didn't catch that falsification, and
issued the cert anyway, that's a bad CA.
Think of a CA as being like an issuer of drivers' licenses or other
forms of ID. If the party named on the ID does something bad, that's
not any reflection on the issuer of the ID. You don't get mad at the
Department of Motor Vehicles (or whoever issues drivers' licenses
where you live) when someone drives badly and hits you. But you might
get mad at the DMV if they issued a driver's license with a false name
or false address. That would be a fault of the issuer.
So, if someone gets a certificate from a CA, a certificate whose facts
are accurate, and then uses it to commit fraud, you have no business
wanting to attack the CA for it. Your beef with a CA should be that
the CA failed to do what the CA said he would do to verify the info that
he signed (the "signed attrbutes") in the cert. Got that?
And if you find that an cert holder has falsified information in his cert
and it was undetected by the CA, you should first approach the CA with
that info. The CA might revoke the cert, if you have a good case.
Point 2: Every browser has its own separate default list of CAs.
Microsoft's list is kept in Windows' "certificate store", part of which
is in the system registry. All the info about the certs is kept in that
store. Windows' cert store is updated by a program available from
Microsoft that adds new certs to the store. MS updates their list
periodically (maybe twice a year).
Mozilla products (including FF, TB, SM, ...) keep their default list
in NSSCKBI.DLL. It is updated (by replacement) in new product releases.
Mozilla products also have a cert data base (cert8.db) that holds new
certs that a user might add, and records information about certs that a
user has chosen to explicitly trust or distrust. (More on that below).
Opera has its own cert store too, but I don't know much about that.
Likewise Safari and others.
As far as I know, none of these products interfere with each others'
cert stores. Mozilla doesn't mess with windows' cert store, and (AFAIK)
vice versa.
So, if you find a CA cert in your windows registry, it didn't come from
mozilla browsers, and it doesn't affect mozilla browsers. If you're
looking for the source of that cert in Window's cert store, look
elsewhere than mozilla browsers.
(This whole issue started over a cert in Windows' registry. So why is this
being discussed in a mozilla group?)
Point 3. CA certs are not added casually to mozilla's list.
Before a CA's cert can be added to mozilla, the CA must go through a
multi-step process to prove that they do business the way they say they do.
That process is all explained in mozilla's CA cert policy, a document
written by Frank Hecker (Executive Director of mozilla foundation, IIRC).
Here is a slightly (?) oversimplified explanation of that process.
The CA must first have (write) a public statement that explains how they work.
It must define their procedures, and explain what things they check before
issuing a cert. This is a "Certified Practices Statement" or "CPS".
And the CA must have some independent party (usually an auditor or CPA)
audit them and check that they really do operate according to the rules
they publicly establish for themselves.
For MOST CAs, these audits are done by "WebTrust", an outfit that exists
to audit CAs (among others). It's operated by the American Institute of
Certified Public Accountants" (AICPA) and the Canadian Institute of
Chartered Accountants" (CICA). There are others that could do this too.
The full requirements are in mozilla's policy, and I won't go into them
here. You suggested that SpywareBlaster might do this. Maybe they could
if they're into auditing. That's a policy question.
When WebTrust does a CA audit, and the CA passes, WebTrust issues a
"seal" for them. You can see a list of exemplary CAs with WebTrust seals
at http://www.webtrust.org/abtseals.htm
The seals listed there each have an "unqualified attestation" (meaning the
attestation doesn't have any provisional parts, no if's, and's or but's).
You'll find Quo Vadis listed on that page. (go look!)
When the audit is done, a request is made to mozilla, asking for inclusion
of the root CA cert. If the site meets the criteria of mozilla's policy
and has passed its audit, and there is no unresolved public objection to
inclusion of the cert during the public comment period, then the cert will
be accepted. Not all applicants get approved.
That's the process that Quo Vadis went through. There are public records
of the application and the discussion about it. See them at
https://bugzilla.mozilla.org/show_bug.cgi?id=238381
Perhaps I've misremembered a few details of this process, details that are
minor with respect to the point here, which is that there is a public and
open process by which CAs are chosen. There's nothing "automatic"
about it. It's not easy for bad guys to get in.
Point 4: You want users to have control, but you don't want to require
them to exercise that control very often. Updates are a good thing.
You already know that mozilla has a "certificate manager" window that
you can bring up from preferences. And it shows you all the cert's
contents in pretty form. So, that lays to rest the accusation that there
is no UI for cert management in mozilla, or that you can only see binary.
Perhaps you'd like mozilla to say to the user, at each update, for each
new cert, something like this: "Here is a new cert that is being added
to your browser's list of CAs. Do you want to trust it?"
How would users answer that question? 49% would always click yes,
and 49% would always click no. 1% would flip a coin, or call their
brother in law, and 1% would switch to a different browser. :)
Did any of them benefit from that exprience?
Can you imagine every browser user in the world having to decide
whether or not to trust a new cert that claims to be from Verisign?
How many of them would have ANY idea how to decide that?
If users had to add new certs to their list of trusted CA certs themselves,
and didn't get new certs from their browser makers, then the users would
be forced to manage all their root CA certs themselves.
That would be a phisher's bonanza! Users would be overrun with email
trying to persuade them to download and trust root CA certs from random
web sites, certs that have had no webtrust audit (or equivalent), certs
that might come directly from the phishers themselves. To be blunt,
that would be a disaster.
If widely used, audited, vetted public CA certs were not added to mozilla
(or IE or other browsers) in updates, then the most likely alternative is
that users would experience Many Many web sites with error messages saying
their certs come from unknown issuers. And users would respond to that the
way most users always respond to that: they'd "click through" it, overriding
the error and proceeding anyway. The more times they see that dialog, the
more likely they are to always click through it. It's the rareness of
that dialog that makes users ever stop and take notice of it.
Users in closed environments (e.g. in corporate enterprise settings)
may need to add their company's root CA cert to their browser. That's
a legitimate case that a user should RARELY have to do. Likewise, if a
root CA should go "rogue" and start issuing falsified certs, a user
should have a way to STOP honoring that issuer's certs. mozilla
provides both of those capabilities. But the use of those should be
exceeding rare, or else you have phishers' bonanza! Users should
manage their certs when they're setting up their browser, not daily,
and certainly not in response to phishing messages!
Point 5: You don't stop bad CAs by forgetting them.
If a user finds that he no longer wishes to "trust" a CA, and no longer
wants his browser to honor certs from that CA, the thing to do is NOT to
delete the cert.
User's sometimes mistakenly assume that every cert listed in the cert
manager is implicitly trusted. So, if the user doesn't want to trust a
cert, the user tends to assume that he should delete it.
But there's a difference between encountering a cert from an issuer of
whom you have no record, and encountering cert from an issuer that you've
seen before and have decided NOT to trust. In one case, you might wanna
go see if they're trustworthy. In the other case, you appreciate that
reminder that you've already decided this is a bad guy, and you're not
tricked into trusting them again, or wasting time re-evaluating them.
So, it's better to keep a cert from a bad guy, and mark it deliberately
untrusted, than to delete it, and lost all record of whether it was
ever trusted before, or not.
That's why mozilla doesn't let the user delete certs from NSSCKBI.DLL.
Instead, mozilla lets the user mark the cert explicitly untrusted.
This is done by "editing" the trust on the cert. You can trust or
distrust a cert separately for different purposes. For example, you
can trust a cert for (say) email, but not for SSL servers. You can
trust a cert for SSL, but not for signing code that you download and run.
So, don't be alarmed about not deleting root CA certs. You really want
to DISTRUST them, not delete them.
Point 6: Old root CA certs retain value, even after they expire.
(hey, it's way late here. I'll write more about this later in the
week, if anyone cares.)
One parting remark. (Is this point 8?)
In the numerous discussions of this that I've read, especially
http://www.wilderssecurity.com/showthread.php?t=140217
I've read that BoClean regards the update program that adds Quo Vadis's
cert to the windows cert store as a trojan horse. The accounts I've
read don't name the program file.
Might it be a copy of Microsoft's own cert update program?
You can download a small program that will update the MS Windows cert
store with new CA certs including Quo Vadis's directly from Microsoft at
http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe
I wonder if perhaps that is the program that started all this misdirected
attention towards mozilla. Imagine a Microsoft update program being
identified as a "Quovadis trojan"!
--
Nelson B
Mele
not the cert was disabled it wasn't clear to me that "edit" was what I
wanted to use to accomplish that as I didn't want to "edit" anything. Fx
Help is of little help when it comes to this entire area of Certificate
Management. That section of Help really needs a HUGE rewrite. Your
explanation is excellent. Why can't something like it be incorporated into
Help? I think the Certs section of Help is the skimpiest, most
unsatisfactory area. Even Help for Fx 2.0 beta 1 is poor in this regard.
I'm glad you filed a bug report and I will follow the progress of this bug
(too tired now to look at it...but I will and I will put myself on the
mailing list).
I have another question: How do the profiles affect, if at all, the certs? I
am asking partly because I recently installed Fx 2.0 beta 1 on a virtual
machine running XP Pro SP1. I already had Fx 1.0.6 on that machine. I have 2
profiles for 1.0.6. On 2.0, earlier tonight, I used the second profile "Umi"
for the first time with 2.0. I looked at the Certificate list and when I
clicked on beTRUSTed Baltimore cert I was informed that it could not be
verified for "unknown reasons". I closed Fx and then opened Fx 1.0.6 and
chose the "Umi" profile. I rarely used this profile on 1.0.6 and had never
used it until tonite with 2.0. Anyhow, I check the same cert and on this
version of Fx it says the cert cannot be verified because the issuer is not
trusted. I am positive that I have never tried to delete ANY cert from this
profile on this version of Fx on my virtual machine. I don't believe I ever
tried to delete beTRUSTed Baltimore cert on Fx 1.5.0.4 on my host machine
either. I don't recall doing that and logically if I had decided (and have
now forgotten) that beTRUSTed was "bad" and I wanted to delete the certs, I
certainly would never have deleted only one of beTRUSTed but would have
deleted all of them and the others all verify. Plus, on my host machine, the
profile that I use is NEW, as of just a few weeks ago, (I have my profiles
go corrupt very frequently and have to create new profiles) and I would
remember if I had tried to delete a cert in the past few weeks. So, I think
there is something else going on with the beTRUSTED Baltimore cert which may
be unique in this respect for some odd reason.
As to GoDaddy cert, I have been experimenting with it on Fx, on both my host
and virtual machines, and with all three versions of Fx I have. It behaves
in the manner that you described for ABA.ECOM root CA.
Before I fall asleep here:
beta.microsoft.com
blogs.technet.com
Two sites that Fx says the certificate cannot be trusted. There are not as
many Microsoft secure sites with this problem as there were even six months
ago. I no longer get that popup from Fx when I logon to Passport and used to
get it then also. There are more than the two I listed though...I just can't
think of them right now. I believe mostly on technet.
I hope this is half way coherent...I must get some sleep.
"Frank Hecker" <hec...@mozillafoundation.org> wrote in message
news:44C6EA5D...@mozillafoundation.org...
Frank Hecker
> Help is of little help when it comes to this entire area of Certificate
> Management. That section of Help really needs a HUGE rewrite. Your
> explanation is excellent. Why can't something like it be incorporated into
> Help? I think the Certs section of Help is the skimpiest, most
> unsatisfactory area. Even Help for Fx 2.0 beta 1 is poor in this regard.
Two quick points:
1. This is an open source project, and as such anyone is welcome to help
out and improve the help text, if there are any volunteers out there who
have the time and interest in doing this.
2. If volunteers aren't forthcoming, this may be an area where it's
worth the Mozilla Foundation making a grant or two to support work in
this area. To the NSS/PSM developers: If you know of anyone interested
and capable of doing this work, please feel free to contact me.
> I have another question: How do the profiles affect, if at all, the
> certs?
I'll leave this question to someone else, as I don't know the answer
"off the top of my head" and don't have time right now to investigate
the question.
> Before I fall asleep here:
>
> beta.microsoft.com
> blogs.technet.com
>
> Two sites that Fx says the certificate cannot be trusted.
I looked into this topic a bit, and found a blog post addressing this
general question, as well as a Bugzilla bug report:
http://blogs.msdn.com/larryosterman/archive/2004/06/04/148612.aspx
https://bugzilla.mozilla.org/show_bug.cgi?id=245609
The short answer is that the Microsoft servers in question are not
configured as typically recommended for SSL and TLS. They send to the
browser an SSL/TLS server certificate, but do not send the rest of the
certificates in the so-called "certificate chain", i.e., the certificate
of the intermediate CA issuing the server cert (Microsoft Secure Server
Authority in this case), the cert of the intermediate CA above that, and
the cert of the root CA at the top of the hierarchy.
In this case it appears that Firefox (and other Mozilla-based products)
actually have pre-loaded the root CA under which the Microsoft CA certs
are issued, but because the Microsoft servers don't send the full cert
chain Firefox doesn't know which root CA is the one to use.
IE doesn't throw an error because Microsoft chose a different way of
handing the case when a full cert chain isn't sent from the server. I'll
simply say that there's legitimate disagreement over whether the
Microsoft approach is actually consistent with the relevant standards,
and leave it at that.
(We've had frequent discussions in the mozilla crypto forum about this
issue, and I don't have time to try to summarize all the differing
positions and their pros and cons.)
> There are not as
> many Microsoft secure sites with this problem as there were even six months
> ago.
That's because over time Microsoft has reconfigured its servers to be
more in line with what CAs typically recommend.
Frank Hecker
> The generality to which I refer "push" is a basic philosophy that seems
> to pervade an awful lot if not all the net today. Specifically, by not
> making the installed certs both more evident to the user and by not
> making them fully removable by users, FF is "doing what is best" for
> ?the users? or for site publishers?
This is a debate that's been going on for a while re computer security:
To what extent should you actively involve the user in security-related
decisions, vs. in essence making the decision for them. I don't think
there's necessarily a right or wrong answer, because it depends both on
the user and the context.
One major issue (as Nelson Bolyard noted) is that presenting users with
a lot of dialogs and decisions ("Accept this cert? Yes or no?") runs the
risk of training people to just click "OK" on everything that gets in
the way of whatever they're trying to do (or at least, what they think
they're trying to do -- because they may have been misled by an attacker).
> Perhaps today our browsers just
> may be trying to do too much and do not allow the user to effectively
> block "unneeded" frills. A summary on that would be that most of us
> block all flash and view sites that rely on flash as both security
> risks (5 flash vulns in last 6 months) and unnecessary marketting hype.
Based on your use of the term "most of us", I think here you're assuming
that what you and others like you do (or want to do) is automatically
typical of the broader population of browser users. I don't think most
people block Flash; heck, even I don't block Flash, and I'm squarely in
the "power user" category when it comes to security.
So just because you and others like you want to exercise individual
judgment on each and every preloaded CA doesn't in and of itself mean
that the majority of Internet users would want to do so.
> regarding the cert problems: The answer to your which one question is
> "yes both". As far as specifci examples, I do not track that and have
> no desire to do so. As a somewhat tech user, I expect experts to do
> that and I would refer you to at least three entries in the SANS diary
> over the last 6 months on failures to revoke known fraud certs (both
> Twaite and Verisign I believe), failure to verify the cert applicant
> before issuing a cert, and as pointed out above one of the root certs
> has apparently expired.
I looked at the SANS site and didn't see any references to anything like
this, with the exception of the 2001 incident in which Verisign issued a
code signing cert to someone falsely claiming to be a Microsoft
representative. Some pointers (from anyone) would be welcome.
However note that this sort of thing is a judgment call, for various
reasons: Is a problem reported for a particular CA an isolated incident,
or does it indicate a systemic problem with the CA? Also, what's the
benefit of removing or disabling a particular CA's root certs vs. the
impact on users and sites of doing so. It's an unfortunate fact of life
that in practice it is much less disruptive to remove a root CA cert for
a small CA than for a CA with significant market share, so in theory a
large CA could probably "get away with more" than a small CA in terms of
sloppy practices, secure in the knowledge that it was "too big to
disable". (I might add that this situation is not helped by the trend of
consolidation in the CA industry.)
I think that actually removing CA certs is like the "atomic bomb" of
browser security: a good threat to have but one you'd want to think very
carefully before using due to the inevitable fallout. In practice I
think browser suppliers, including us, will focus more on getting CAs to
revoke bad certificates quickly and on improving browser support for
doing certificate revocation checking by default "out of the box" (e.g.,
automatically querying OCSP responders for those CAs providing them).
(There's been work in Firefox and other Mozilla products relating to
this topic, but I'll leave this to the developers to address, because I
don't recall the exact current state of this work.)
> So are you saying that FF has fully proofed
> the root certs? If not, then the following of a proceedure did not
> seem to have eliminated questionablly operated root certs.
I'm not sure what you mean by "fully proofed". For new CA certs (i.e.,
added since the Mozilla Foundation was formed and since we had the new
CA certificate policy) we went through the procedures discussed in the
CA policy and evidenced in the Bugzilla records. For "legacy" CA certs
(i.e., inherited from the AOL/Netscape regime) we haven't yet gone
through and subjected them to the same process. Instead we're adopting a
"management by exception" policy where we'll look at a particular CA if
someone reports a potential problem with it.
> sleepy & tired
Go to bed and enjoy your rest :-)
Bill
check that you haven't config'd FF to use OCSP for certificate
verification.
If you have the browser set for OCSP verification but the cert can't be
verified in this way, you'll get the failure you report.
Go to Tools -> Options -> Advanced -> Security and click the
Verification button. I'd recommend either option 1 (turn off OCSP
verification) or option 2 (only use OCSP for those certs that support
it). Hope that helps.
Frank, Nelson - great posts and very good summaries on how certs are
supposed to work!