How to delete root certs for Chrome under Linux?
Peter Pearson
and would like to delete from its root-certificate set all the
many certificates of distant and obscure authorities that I have
no reason to trust.
When I ask Chrome to manage certificates (Wrench / Options /
Under the Hood / Manage Certificates), I get a web page
instructing me to download libnss3-tools and use the
certutil utility. Done. When I ask certutil to list all
certificates, I get no certificates, so I guess this is a
mechanism for managing *additional* certificates. From
http://code.google.com/p/chromium/issues/detail?id=10911, I
see this:
NSS stores its built-in root CA certificates in the shared
library libnssckbi.so, which is equivalent to Debian's
ca-certificates except that it's read-only.
Since libnssckbi.so appears to be executable, this sounds as
if root certificates are compiled in. Ugh! Really?
Can anyone tell me how to manage Chrome's root certificates
under Linux?
--
To email me, substitute nowhere->spamcop, invalid->net.
Tom St Denis
> I'm considering adopting Google's Chrome as my default browser,
> and would like to delete from its root-certificate set all the
> many certificates of distant and obscure authorities that I have
> no reason to trust.
Generally speaking root CAs don't mean much of anything. Just because
company A signs some other companies cert doesn't mean the other
company can be trusted, nor does it mean that company A will reimburse
you for lost goods or money.
What you should be concerned with is the accuracy of your DNS
resolution and if the certificate matches the domain you think you're
at.
Tom
Paul Rubin
> Generally speaking root CAs don't mean much of anything. Just because
> company A signs some other companies cert doesn't mean the other
> company can be trusted, nor does it mean that company A will reimburse
> you for lost goods or money.
Company A's signature on company B's cert isn't supposed to mean company
B is necessarily trustworthy. It just means company A attests that the
cert is actually from company B and not an imposter.
There have been some significant doubts raised about CA's in certain
countries that like to monitor internet activity. The concern is that
the governments of those countries might be using those CA's to forge
certificates and run MITM attacks.
Tom St Denis
Scenario: Friend recommends I check out a Blastonic E-reader. I've
never heard of the company but insists I go check it out. I trust my
friend if he had a good experience I will give it a shot.
I go to blastonic.com (I hope that doesn't exist, I just made up the
name) and see, phew, I made it, Verisign signed the cert from the
website. Now I'm good to go enter my CC number!
...
Right.
The real problem is we have a billion websites out there and even if
they all had valid certs it wouldn't matter.
What would be more important is for websites to use merchant systems
that don't expose a lick of customer data to them. Why should Amazon
know my CC# just so I can buy something? That should be between me
and my bank.
The real security risk with the internet is that we have to keep
divulging secrets to everyone to get anything done. It doesn't matter
if I sent a website my CC# over TLS if all they do is backup the DB
onto a laptop and leave it in a car at a baseball game.
Tom
Paul Rubin
> What would be more important is for websites to use merchant systems
> that don't expose a lick of customer data to them. Why should Amazon
> know my CC# just so I can buy something? That should be between me
> and my bank.
Right, that's why Paypal exists, and Visa and Amex (and maybe others)
have done some services where they issue a temporary card number for a
single transaction or group of transactions with a single merchant. So
the merchant can't then spill the number to someone who uses it all over
the place. That has nothing to do with certificates.
See, the issue with these weird CA's is only partly about stuff like
credit cards. It's also that they can be under the control of (say) the
Indian government, which probably doesn't care about spoofing Amazon.com
and getting your CC#, but might well want to spoof GMail.com and read
your private correspondence if you're writing to an Indian person
(including possibly an Indian person in Canada) or someone else of
interest to them. I mention India because they're currently pressuring
RIM to give them access to encrypted email sent to and from
Blackberries, but you can see how the issue generalizes. Once a root
cert from such a CA is in enough browsers, the Indian government can
spoof the whole web.
Peter Pearson
>
> See, the issue with these weird CA's is only partly about stuff like
> credit cards. It's also that they can be under the control of (say) the
> Indian government, which probably doesn't care about spoofing Amazon.com
[snip]
Indeed, at http://www.schneier.com/blog/archives/2010/09/uae_man-in-the-.html
is a discussion of the profusion of organizations that are "automatically
trusted by most browsers", including a UAE mobile-phone company
named Etisalat. So if some UAE governmental body wants to do a
man-in-the-middle attack on your "secure" browsing, it probably
can . . . unless you've disabled the corresponding root certificate.
My fanaticism on this subject dates from 2008, when Comodo,
which enjoys default built-in root cert authority on *your*
browser, delegated signature authority to Certstar, which
did so little "due diligence" that when Eddy Nigg asked them
to sign a cert for "mozilla.com", they did!
Amazingly, Comodo is still a default built-in root cert
authority, despite having blatantly failed to do the one
thing, the only thing, that we end users ask them to do,
namely not stand behind bogus certificates. This shows
that we can't leave built-in root cert decisions up to the
browser makers.
My big concern is not credit-card fraud but rather the
vulnerability of online banking. It's only a matter of time
before some criminal organization bribes a bureaucrat at the
least diligent of the 70-odd organizations on the default
built-in root cert list (or the who-knows-how-many
organizations that exercise delegated authority from them)
to get a certificate in the name of Bank of America. Then
they'll mount a man-in-the-middle attack, grab my password
and empty my account.
By disabling all but the essential handful of built-in root
certs, I greatly increase the odds that I'll get a warning
message during that man-in-the-middle attack. I'm surprised
everybody on this list isn't clamoring to do the same.
Paul Rubin
> My fanaticism on this subject dates from 2008, when Comodo...
> did so little "due diligence" that when Eddy Nigg asked them
> to sign a cert for "mozilla.com", they did!
> Amazingly, Comodo is still a default built-in root cert
> authority, despite having blatantly failed to do the one
> thing, the only thing, that we end users ask them to do,
> namely not stand behind bogus certificates.
To be fair, there was a ton of drama on the Mozilla bug tracker after
that incident, and I think some reasonable assurance that Comodo wasn't
going to repeat that exact mistake. You'll remember there was another
incident where someone got Verisign to issue a bogus code signing cert
with "Microsoft Corporation" as the signer.
> It's only a matter of time before some criminal organization bribes a
> bureaucrat at the least diligent of the 70-odd organizations on the
> default built-in root cert list ... to get a certificate in the name
> of Bank of America.
> By disabling all but the essential handful of built-in root
> certs, I greatly increase the odds that I'll get a warning
> message during that man-in-the-middle attack. I'm surprised
> everybody on this list isn't clamoring to do the same.
That is what so-called extended validation certificates are supposed to
help with. Almost all FI's use them these days, there aren't as many
issuers, and the browser nav bar looks different with those certs. In
fact it bothers me somewhat that a small operation like Eddy Nigg's (not
that Eddy is a bad guy or anything like that) was able to become an EV
cert authority.
Jeffrey Walton
>
> There have been some significant doubts raised about CA's in certain
> countries that like to monitor internet activity. The concern is that
> the governments of those countries might be using those CA's to forge
> certificates and run MITM attacks.
See "Certified Lies: Detecting and Defeating Government Interception
Attacks Against SSL" by Christopher Soghoian and Sid Stamm, though the
authors don't present any evidence of the practice.
Tom St Denis
> Tom St Denis <t...@iahu.ca> writes:
>
> > What would be more important is for websites to use merchant systems
> > that don't expose a lick of customer data to them. Why should Amazon
> > know my CC# just so I can buy something? That should be between me
> > and my bank.
>
> Right, that's why Paypal exists, and Visa and Amex (and maybe others)
> have done some services where they issue a temporary card number for a
> single transaction or group of transactions with a single merchant. So
> the merchant can't then spill the number to someone who uses it all over
> the place. That has nothing to do with certificates.
Except paypal != my bank, it's just yet another third party. I have a
VISA card, sure it's issued by a local bank but it's still VISA. Why
can't VISA host a service [to all customers] that allows me to not
give a merchant JACK SQUAT about my financials other than "money made
it into your account?"
> See, the issue with these weird CA's is only partly about stuff like
> credit cards. It's also that they can be under the control of (say) the
> Indian government, which probably doesn't care about spoofing Amazon.com
> and getting your CC#, but might well want to spoof GMail.com and read
> your private correspondence if you're writing to an Indian person
> (including possibly an Indian person in Canada) or someone else of
> interest to them. I mention India because they're currently pressuring
> RIM to give them access to encrypted email sent to and from
> Blackberries, but you can see how the issue generalizes. Once a root
> cert from such a CA is in enough browsers, the Indian government can
> spoof the whole web.
GPG your email from the source. Do things properly.
Tom
Jeffrey Walton
> Tom St Denis <t...@iahu.ca> writes:
>
>
> See, the issue with these weird CA's is only partly about stuff like
> credit cards. It's also that they can be under the control of (say) the
> Indian government, which probably doesn't care about spoofing Amazon.com
> and getting your CC#, but might well want to spoof GMail.com and read
Let's not forget about all the possible actors. The United States
government is no choir boy, with tools such as the PATRIOT Act (which
I like to fondly refer to as Gestapo Legislation).
Jeffrey Walton
Mok-Kong Shen
> Indeed, at http://www.schneier.com/blog/archives/2010/09/uae_man-in-the-.html
> is a discussion of the profusion of organizations that are "automatically
> trusted by most browsers", including a UAE mobile-phone company
> named Etisalat. So if some UAE governmental body wants to do a
> man-in-the-middle attack on your "secure" browsing, it probably
> can . . . unless you've disabled the corresponding root certificate.
[snip]
A very dumb question: Are there absolutely solid reasons to support
a thinking that certificate authorities run by private organizations
are unconditionally more trustworthy than ones that, say, are
officially run by the governments? (I mean there is an analogy to
comparing private banks with central banks.)
M. K. Shen
Tom St Denis
> Peter Pearson wrote:
> > Indeed, athttp://www.schneier.com/blog/archives/2010/09/uae_man-in-the-.html
Actually for once you're spot on. That's basically what I've been
saying all along. What does it *mean* for Verisign to sign your
cert? Who are they and why should I trust them?
Tom
Peter Pearson
> . . . You'll remember there was another incident where
> someone got Verisign to issue a bogus code signing cert
> with "Microsoft Corporation" as the signer.
No, I didn't remember that. Ugh. I don't think I have the stomach
to tear Verisign out of my root-cert list.
[snip]
> That is what so-called extended validation certificates are supposed to
> help with. Almost all FI's use them these days, there aren't as many
> issuers, and the browser nav bar looks different with those certs.
Hey, thanks for pointing that out. I didn't know, and it sounds useful.
Peter Pearson
>
> A very dumb question: Are there absolutely solid reasons to support
> a thinking that certificate authorities run by private organizations
> are unconditionally more trustworthy than ones that, say, are
> officially run by the governments? (I mean there is an analogy to
> comparing private banks with central banks.)
I hope I didn't appear to be expressing a bias toward
governmental CA's or private CA's. I just want the
community of informed-users-who-care to be able to
exercise their judgment as easily as possible.
Mok-Kong Shen
> I hope I didn't appear to be expressing a bias toward
> governmental CA's or private CA's. I just want the
> community of informed-users-who-care to be able to
> exercise their judgment as easily as possible.
I personally think that it's very fine that you brought
up the issue to refresh people's mind of the existence
of problems in the field concerned. (In fact a question
that I time and again ask myself is 'How much should/could
one trust the trust centres?')
M. K. Shen
Nelson Bolyard
> I'm considering adopting Google's Chrome as my default browser,
> and would like to delete from its root-certificate set all the
> many certificates of distant and obscure authorities that I have
> no reason to trust.
You really don't want to delete the certificates. Instead, you want
to mark (some of) them explicitly untrusted. It accomplishes your
goal, and it remembers that you've explicitly made this decision,
unlike deleting certs, which only forgets that you ever knew about
these roots.
> When I ask Chrome to manage certificates (Wrench / Options /
> Under the Hood / Manage Certificates), I get a web page
> instructing me to download libnss3-tools and use the
> certutil utility. Done. When I ask certutil to list all
> certificates, I get no certificates,
First, Did you use the "-h all" option?
Second, Did you try pointing it with the -d option to the directory where
your browser's cert*.db and libnssckbi.so files live?
> so I guess this is a
> mechanism for managing *additional* certificates.
It's also that, but not only that.
> From
> http://code.google.com/p/chromium/issues/detail?id=10911, I
> see this:
>
> NSS stores its built-in root CA certificates in the shared
Key word there is "built-in", to distinguish them from the ones
you might add yourself.
> library libnssckbi.so, which is equivalent to Debian's
> ca-certificates except that it's read-only.
>
> Since libnssckbi.so appears to be executable, this sounds as
> if root certificates are compiled in. Ugh! Really?
Yes, the default set is compiled in. That's not to your disadvantage.
You don't want to delete any. You want to edit trust. Trust is
entirely editable on those certs.
> Can anyone tell me how to manage Chrome's root certificates
> under Linux?
You're already close. You've got the right tools. You may need to
point them at the right directories with command line options such
as -d <directory>. (Sadly, different Linux distros tweak directory
names, so not all copies of NSS find each other's files without help.)
I suggest you ask further questions about this in NSS's discussion group
news://news.mozilla.org:119/mozilla.dev.tech.crypto
Peter Pearson
> On 2010-09-06 10:53 PDT, Peter Pearson wrote:
>> I'm considering adopting Google's Chrome as my default browser,
>> and would like to delete from its root-certificate set all the
>> many certificates of distant and obscure authorities that I have
>> no reason to trust.
>
> You really don't want to delete the certificates. Instead, you want
> to mark (some of) them explicitly untrusted. It accomplishes your
> goal, and it remembers that you've explicitly made this decision,
> unlike deleting certs, which only forgets that you ever knew about
> these roots.
Good point. My posture is better represented as "I have
decided not to trust this CA" than as "I've never heard of
this CA."
>> When I ask Chrome to manage certificates (Wrench / Options /
>> Under the Hood / Manage Certificates), I get a web page
>> instructing me to download libnss3-tools and use the
>> certutil utility. Done. When I ask certutil to list all
>> certificates, I get no certificates,
>
> First, Did you use the "-h all" option?
Ha! That makes a world of difference. Thank you, thank you.
Combined with your observation that I can edit the trust for
the built-in certificates, this should get me going.
Peter Pearson
Here's a report on my adventures, which appear successful.
$ certutil -d sql:$HOME/.pki/nssdb -L -h all >certs.tmp
wrote into certs.tmp a large number of lines that look like this:
Builtin Object Token:Thawte Server CA CG,,C
The "CG,,C" field at the end is the "trust attributes", partly
described in the output of "certutil -H". The three subfields
apply to SSL, S/MIME, and JAR/XPI (object signing), respectively.
$ certutil -d sql:$HOME/.pki/nssdb -L \
-n "Builtin Object Token:Comodo AAA Services root"
gets a detailed listing of that one cert.
$ certutil -d sql:$HOME/.pki/nssdb -M \
-n "Builtin Object Token:Comodo AAA Services root" \
-t c,c,c
replaces the "trust attributes" of that cert, which were "C,C,C",
with "c,c,c". I believe the lowercase c means "valid CA, but
not trusted". (More accurately, I think this certutil command
creates some kind of private, local, non-built-in shadow of the
original certificate, and assigns the "c,c,c" trust to that
shadow. Subsequently running "certutil [snip] -L -h all" displays
more entries, with and without the "Builtin Object Token:" prefix.)
So, I edited the certs.tmp file produced by the first command to
produce a shell script that invoked certutil about 100 times and
switched a lot of C's to lowercase.
Now, when I browse with Google Chrome to an SSL-protected
site whose certificate chain ends in a certificate whose "C"
I lowercased, Chrome pops up a warning window saying "The
site's security certificate is not trusted!" and offering me
the options of "Proceed anyway" and "Back to safety". If I
proceed anyway, the "https:" in the address bar is red and
crossed out (cute). I'm sad that Chrome doesn't offer me a
"Save this cert and trust it from now on" button. I suppose
when the need arises, I'll achieve that by "viewing" the
certificate, "exporting" it, and then finding another certutil
command to add it to my private cert collection.
Nelson Bolyard
> On 10 Sep 2010 19:46:01 GMT, Peter Pearson wrote:
> Here's a report on my adventures, which appear successful.
[snip]
> $ certutil -d sql:$HOME/.pki/nssdb -M \
> -n "Builtin Object Token:Comodo AAA Services root" \
> -t c,c,c
> replaces the "trust attributes" of that cert, which were "C,C,C",
> with "c,c,c". I believe the lowercase c means "valid CA, but
> not trusted".
Correct.
> (More accurately, I think this certutil command
> creates some kind of private, local, non-built-in shadow of the
> original certificate, and assigns the "c,c,c" trust to that
> shadow. Subsequently running "certutil [snip] -L -h all" displays
> more entries, with and without the "Builtin Object Token:" prefix.)
Yes. Those entries are in your $HOME/.pki/nssdb/cert9.db file.
[snip]
> Now, when I browse with Google Chrome to an SSL-protected
> site whose certificate chain ends in a certificate whose "C"
> I lowercased, Chrome pops up a warning window saying "The
> site's security certificate is not trusted!" and offering me
> the options of "Proceed anyway" and "Back to safety". If I
> proceed anyway, the "https:" in the address bar is red and
> crossed out (cute). I'm sad that Chrome doesn't offer me a
> "Save this cert and trust it from now on" button. I suppose
> when the need arises, I'll achieve that by "viewing" the
> certificate, "exporting" it, and then finding another certutil
> command to add it to my private cert collection.
There's another browser that runs on Linux, uses those same NSS DBs
and .so's, and has a second or third generation GUI for administering
trust and adding "exceptions" for hosts you want to trust even if their
certs don't chain to trusted roots. In fact, there are a couple such
browsers: Firefox and SeaMonkey. Why do they not appeal to you?
Peter Pearson
First, thank you for your advice in this thread.
I haven't heard of SeaMonkey, but I wouldn't mind trying
it. I'm attempting to wean myself off Firefox because I
don't like listening to 15 seconds of disk thrashing every
time I start it or stop it. I concede that it's probably my
fault for inadvertently allowing some Thing 1 to update
itself into a state that's incompatible with my installed
version of some other Thing 2, and I could probably set it
right with a week of research, but maybe I should just try
Chrome instead.
Also, Chrome didn't just pick up my comfortably broken-in
Firefox certificate database. From what I see, it appears that
my old (Firefox) cert DB is at $HOME/.mozilla/firefox/52glymf5.default,
while Chrome keeps one at $HOME/.pki/nssdb. Also, I just installed
and tried SeaMonkey, which appears to ignore both of those while
using $HOME/.mozilla/seamonkey/x0a01xa2.default. I wonder if I
could use symbolic links to make all three databases the same.