Open
Bug 585352
Opened 14 years ago
Updated 2 years ago
Certificate Manager misleads users into thinking that they can distrust CAs and/or intermediates
Categories
(Core :: Security: PSM, defect, P5)
Core
Security: PSM
Tracking
()
REOPENED
People
(Reporter: geekboy, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [psm-backlog])
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•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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
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.
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.
Group: core-security
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Intermediate CAs without trust bits set are still trusted → Certificate Manager misleads users into thinking that they can distrust CAs and/or intermediates
Updated•14 years ago
|
Assignee: nobody → nobody
Component: Libraries → Security: UI
Product: NSS → Core
QA Contact: libraries → ui
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.
Blocks: 1029832
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 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?
Comment 11•8 years ago
|
||
Adding engineering to put this bug on the radar.
Flags: needinfo?(tanvi)
Flags: needinfo?(dkeeler)
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.
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.
Component: Security: UI → Security: PSM
Flags: needinfo?(tanvi)
Flags: needinfo?(dkeeler)
Whiteboard: [psm-backlog]
Priority: -- → P3
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.
Comment hidden (abuse-reviewed) |
(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 hidden (abuse-reviewed) |
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.
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.
Updated•2 years ago
|
Severity: normal → S3
Comment 21•2 years ago
|
||
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.
Flags: needinfo?(dkeeler)
Comment 22•2 years ago
|
||
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.
Flags: needinfo?(dkeeler)
You need to log in
before you can comment on or make changes to this bug.
Description
•