Closed Bug 1409872 Opened 4 years ago Closed 4 years ago

remove entries for expired actively distrusted certs

Categories

(NSS :: CA Certificates Code, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
3.34.1

People

(Reporter: keeler, Assigned: keeler)

References

Details

Attachments

(2 files)

We have some expired actively distrusted certificates in the builtin CA database that we can remove.
Comment on attachment 8919901 [details]
bug 1409872 - remove active distrust entries for certificates that have expired r?ttaubert,kaie

Tim Taubert [:ttaubert] has approved the revision.

https://phabricator.services.mozilla.com/D139#3194
Attachment #8919901 - Flags: review+
Kai, I just wanted to make sure you saw this review request (are you set up with an account on phabricator.services.mozilla.com?)
Flags: needinfo?(kaie)
Isn't this related to or even a duplicate of bug 829677?
They're related but slightly different. This deals with expired entries that we no longer need.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #2)
> Kai, I just wanted to make sure you saw this review request (are you set up
> with an account on phabricator.services.mozilla.com?)

I was on PTO last week.

It seems I do have an account, but so far I've only played with the NSS area, not yet with the mozilla one.

I think I didn't receive an email with a review request from that system.
Could you please ask me for review again on a bogus change?
Thanks
Flags: needinfo?(kaie)
A certificate simply listed as expired might cause users to incorrectly conclude it's less problematic, and that adding an override might be ok.

In the past we were reluctant to remove these, because the explicit distrust has the additional effect that manual overrides are impossible. 

I'm a bit worried about the suggestion to no longer distrust the DigiNotar CAs, in particular about the intermediates. Do these intermediates chain to root CAs that are still valid? I suggest to check that. If yes, then the attacker could decide to reuse these intermediates for new attacks, in the hope that users confirm the "expired" warning of MITM certificates.
(In reply to Kai Engert (:kaie:) from comment #6)
> A certificate simply listed as expired might cause users to incorrectly
> conclude it's less problematic, and that adding an override might be ok.
> 
> In the past we were reluctant to remove these, because the explicit distrust
> has the additional effect that manual overrides are impossible. 
> 
> I'm a bit worried about the suggestion to no longer distrust the DigiNotar
> CAs, in particular about the intermediates. Do these intermediates chain to
> root CAs that are still valid? I suggest to check that. If yes, then the
> attacker could decide to reuse these intermediates for new attacks, in the
> hope that users confirm the "expired" warning of MITM certificates.

Getting a user to click "add exception" for another error of the same severity (like hostname mismatch or unknown issuer) is about as difficult as getting a user to add an exception for an expired certificate, so I don't think we're preventing any attacks by continuing to have these expired entries.
Kai, thoughts about comment 7?
Flags: needinfo?(kaie)
David, I believe that currently the protection for DigiNotar mississued certificates is stronger, because it is impossible to add an exception for a chain that involves a distrusted certificate, even after it has expired. At least that is the behavior when using NSS verification calls, and it was the behavior when Firefox still used NSS verification in the past. I haven't checked the mozilla::pkix behavior.

(Should I be wrong, my comment is irrelevant, because that protection has been removed already, at least from Firefox, but is still present for other NSS based applications.)

If I'm right: Are you comfortable downgrading the protection against the malicious owners of the DigiNotar CA keys from "cannot override distrusted chain" to "can override expired chain with exception"?

I'm not sure if we still require the "cannot override" protection several years after the incident. At least I'm nervous about removing it. Would it make sense to ask the community in dev-security-policy?
Flags: needinfo?(kaie) → needinfo?(dkeeler)
I realize that I should look at it differently.
If we remove the distrusted entries, what will be the consequence?

An attacker owning the private keys has the choice using the old keys of the DigiNotar CA to create a rogue certificate.
A user visiting a rogue site using that certificate will see an "expired" error message.

If we keep distrusting those CAs, an attacker would have to use an untrusted or mismatching certificates.

So the question is, are users more likely to add an override for an expired certificates, versus other security warnings?

David says in comment 7 that there isn't a big difference. I cannot quote any studies that suggest otherwise. It's only my personal feeling that some users might be more forgiving/likely to accept an expired certificate.

Does Mozilla have any telemetry data, that says if people are potentially adding overrides for expired certificates more often than for untrusted certificates?

Nevertheless, despite these slight worries, I don't want to veto this change. If users will get expiration errors for all affected certificates, it will hopefully sufficient for all software consuming the CA list.
Flags: needinfo?(dkeeler)
We do have some measurements. It's a little hard to read the tea-leaves here, but https://mzl.la/2hF1X84 indicates that the majority of overrides are for unknown issuer errors (bucket 2), followed by domain mismatch (bucket 9). In relatively distant 3rd place is expired certificates (bucket 10) (bucket <-> error mapping here: https://dxr.mozilla.org/mozilla-central/rev/f41930a869a84af81df1a88d8e82323ff3a6509a/security/manager/ssl/SSLServerCertVerification.cpp#285 ). I understand the reluctance to remove distrust bits (after all, it does remove security-relevant information), but in this case I think the data supports that it isn't necessary to keep around.
https://hg.mozilla.org/projects/nss/rev/fbd5eb8b3fc1
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.35
Every change to the CA list must go with its own version number change.

In file nssckbi.h, please change version 2.18 to 2.20 (in both places).
Flags: needinfo?(dkeeler)
Ah - didn't know that. Follow-up in https://phabricator.services.mozilla.com/D258 (let me know if phabricator isn't working for you)
Flags: needinfo?(dkeeler)
Comment on attachment 8929550 [details]
bug 1409872 - follow-up to bump ckbi version numbers to 2.20 r?kaie

Kai Engert (:kaie:) has approved the revision.

https://phabricator.services.mozilla.com/D258#6265
Attachment #8929550 - Flags: review+
Do you think it's acceptable to apply these distrust removals for Firefox 58?

(If yes, we could use a single CA list version for this bug and bug 1418678.)
Flags: needinfo?(kwilson)
See Also: → 1419760
(In reply to Kai Engert (:kaie:) from comment #17)
> Do you think it's acceptable to apply these distrust removals for Firefox 58?

Yes

> 
> (If yes, we could use a single CA list version for this bug and bug 1418678.)

Thanks!
Flags: needinfo?(kwilson)
Target Milestone: 3.35 → 3.34.1
You need to log in before you can comment on or make changes to this bug.