Sid Stamm [:geekboy or :sstamm] Reporter
	Description • 14 years ago

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.

	Nelson Bolyard (seldom reads bugmail)
	Comment 1 • 14 years ago

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.

	Peter Eckersley
	Comment 2 • 14 years ago

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.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 3 • 14 years ago

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.

	Peter Eckersley
	Comment 4 • 14 years ago

(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.

	JP Donnio
	Comment 8 • 8 years ago

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 :(

	arthur.lutz
	Comment 9 • 8 years ago

+1

	My1
	Comment 10 • 8 years ago

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?

	Stefan Arentz | :st3fan | ⏰ EST | he/him
	Comment 11 • 8 years ago

Adding engineering to put this bug on the radar.

	Frederik Braun [:freddy]
	Comment 12 • 8 years ago

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.

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews)
	Comment 13 • 8 years ago

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.

	Filip Jirsák
	Comment 14 • 8 years ago

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.

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews)
	Comment 16 • 8 years ago

(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.

	adamhm
	Comment 18 • 8 years ago

(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.

	Jakub Vavra
	Comment 20 • 8 years ago

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.