585352 - Certificate Manager misleads users into thinking that they can distrust CAs and/or intermediates

Status: REOPENED

(Core :: Security: PSM, defect, P5)

Description

[Sid Stamm [:geekboy or :sstamm]]

Peter Eckersley reported to me the following problem.  I haven't yet verified it myself, but wanted to file this bug asap.

--- Peter Writes: ---

I have a vulnerability in browser certificate management UIs to report.  It
affects Firefox on all platforms, and Chrome on Linux.  It does not appear to
affect Chrome, Safari or IE on Windows or OS X.  I haven't tested on any
mobile devices.

The issue is that:

1. There is no way to instruct your browser not to trust a particular
Intermediate CA cert.

2. There are several UI pathways that tell the user that they have stopped
trusting the Intermediate CA cert, but this information is misleading.

Suppose, for example, that one does not wish to trust the CA certificates that
belong to Etisalat's Comtrust business unit (you can see these certs in use at
https://www.emirates.com or https://corp.dnata.com).  There are two things you
might try to do in the Firefox or Chrome-on-Linux UI to achieve this.

One is that you might notice that the Etisalat/Comtrust certs are cached after
you've visited a site that used them, and you might go into the certificate
management UI and delete them.  If you do this, you will receive a message
like this:

  Are you sure you wish to delete these CA certificates?

  <common name of intermediate CA>

  If you delete a certificate authority (CA) certificate, this application
  will no longer trust any certificates issued by that CA.

However, this is not true.  Deleting intermediate CA certificates will not
prevent your browser from trusting them in future.

A particularly cunning user might try to work around this problem by pressing
the "edit" button and unchecking all of the permissions for the intermediate
CA cert, such as the "this certificate can identify websites" permission.
These checkboxes appear to have no effect for intermediate certs.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Sid, You need to learn how trust works in NSS.
There is active trust, there is passive (inherited trust), and conceptually,
there is active distrust.  However, active distrust is not fully implemented.
A cert without any trust flags is merely a cert that uses passive trust. 

If you wish to distrust an intermediate CA cert, presently, the only way to 
do it is to remove trust from the ancestor from which it inherits trust, and 
then actively trust its siblings that you do trust.  

This has been explained in newsgroups repeatedly over the last decade. So it's
hardly a secret or a vulnerability.

Comment 2

[Peter Eckersley]

Nelson, the vulnerability is not so much the lack of the active-distrust feature, but the way the UI suggests to the user that they have actively distrusted an intermediate CA.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Another problem with the UI is that the user might try to distrust a CA, but the CA actually has another cert that is chained to another CA's cert, and that alternate trust chain will still allow the certs issued by that CA to work. For example, a user that attempts to distrust the USERTRUST roots probably wouldn't realize that there is another path that allows Comodo to issue certs that use Entrust root.

Comment 4

[Peter Eckersley]

(In reply to comment #3)
> Another problem with the UI is that the user might try to distrust a CA, but
> the CA actually has another cert that is chained to another CA's cert, and that
> alternate trust chain will still allow the certs issued by that CA to work.

Great point Brian.  So what needs to be blacklisted is not just the certificate as a whole, but both the Subject field of the CA and the Public Key of the CA.  These need to be blacklisted separately.

Comment 8

[JP Donnio]

https://news.ycombinator.com/item?id=11781915
Symantec Issues Intermediate CA Certificate for Blue Coat Public Services

This bug needs to be fixed urgently!
Microsoft OS and Mac OS can distrust an intermediate, not mozilla :(

Comment 9

[arthur.lutz]

+1

Comment 10

[My1]

I think this feature is urgently needed as well.

I would love to kick symantec into oblivion but then again many sites probably use them, therefore kicking that one wouldnt be a great solution. especially when you have to add the other intermediates which possibly opens more holes as there are active trust points.

e.g. what happens if symantecs root gets revoked but I have an active trust on one of their certs?

Comment 11

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Adding engineering to put this bug on the radar.

Comment 12

[Frederik Braun [:freddy]]

Please be mindful of Bugzilla etiquette and other people's time.
Use the "vote" button (somewhere up top, depending on the bugzilla theme) instead of writing "me too" comments.
Thank you.

Comment 13

[Dana Keeler (she/her) (use needinfo) [:keeler]]

The certificate manager needs a lot of attention in general, but it might be a while before we can really focus on it. In the meantime, a few small bandaids might be:
1. Don't offer to delete built-in certificates (users can use the "Edit Trust" button to distrust them)
2. Don't use the word "distrust" when what is really meant is "delete"

Since the use-case of wanting to distrust a specific non-built-in intermediate certificate is quite rare for the average user, I really doubt we're ever going to implement a UI that would allow it. However, that's what add-ons are for. I wrote a quick proof-of-concept at https://addons.mozilla.org/en-US/firefox/addon/red-jacket/ . Note that this is not an official Mozilla project or product and comes with no warranty of any kind. It may break your browsing experience. It may also allow you to meaningfully distrust intermediate certificates.

Comment 14

[Filip Jirsák]

Because of this bug, users can not stop trusting certificates WoSign (see https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/k9PBmyLCi8I). Intermediate certificate "Certification Authority of WoSign" (serial no. 19:C2:85:30:E9:3B:36) is cross-signed by StartCom Certification Authority, so users can untrust whole StartCom CA, or they must continue to trust WoSign.

Comment 15

[Doktor Notor]

(In reply to Frederik Braun [:freddyb] from comment #12)
> Please be mindful of Bugzilla etiquette and other people's time.

Please stop wasting time patronizing others about etiquette and start fixing your code. 6 years and counting; ridiculous. Alternatively, you might ditch the entire steaming pile of *bleep* code and start using native system certificate store like everyone else. Oh, wait, that wouldn't get you the dirty money from CNNIC and similar "trusted" CAs.

Comment 16

[Dana Keeler (she/her) (use needinfo) [:keeler]]

(In reply to Filip Jirsák from comment #14)
> Because of this bug, users can not stop trusting certificates WoSign (see
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/
> k9PBmyLCi8I). Intermediate certificate "Certification Authority of WoSign"
> (serial no. 19:C2:85:30:E9:3B:36) is cross-signed by StartCom Certification
> Authority, so users can untrust whole StartCom CA, or they must continue to
> trust WoSign.

The add-on linked to in comment 13 might be helpful for users that want to go that route.

Comment 17

[Doktor Notor]

Has everyone at Mozilla totally lost track of reality lately? Years wasted integrating stuff like Hello, Pocket and similar nonsense which absolutely belongs to addons and not to the browser -- yet genuine bugs in core components are completely ignored and users being told to try some random third-party addon for things like proper certificate chain validation? Priorities upside down, I guess. How about another most fugly logo competition? Might distract the pesky security nerds for a while as well. Sigh.

Comment 18

[adamhm]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #13)
> The certificate manager needs a lot of attention in general, but it might be
> a while before we can really focus on it. In the meantime, a few small
> bandaids might be:
> 1. Don't offer to delete built-in certificates (users can use the "Edit
> Trust" button to distrust them)
> 2. Don't use the word "distrust" when what is really meant is "delete"
> 
> Since the use-case of wanting to distrust a specific non-built-in
> intermediate certificate is quite rare for the average user, I really doubt
> we're ever going to implement a UI that would allow it. However, that's what
> add-ons are for. I wrote a quick proof-of-concept at
> https://addons.mozilla.org/en-US/firefox/addon/red-jacket/ . Note that this
> is not an official Mozilla project or product and comes with no warranty of
> any kind. It may break your browsing experience. It may also allow you to
> meaningfully distrust intermediate certificates.

Most security feathers are "quite rare for the average user", just like nobody needs a firefighter before his house is on fire. I think the ability to managing certificates, including trusting, distrusting and revoking, is a piece of a browser's security core, and should NEVER be the function provided by an add-on.

Comment 20

[Jakub Vavra]

Hello,
as my bug was marked as a duplicate of this one, I just wanted to drop by and note that impossibility to nuke rogue CA certificates (even at the price of dropping their cross-signed friends) from browser is a huge security gap and a big issue for users that want to keep themselves actively more secure from snooping. The bug should not be about that it is misleading, but that deleting CA certs does not work.

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 21 votes.
:keeler, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 22

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.