1409872 - remove entries for expired actively distrusted certs

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task)

Description

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

We have some expired actively distrusted certificates in the builtin CA database that we can remove.

Comment 1

[Phabricator Automation]

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

Comment 2

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

Kai, I just wanted to make sure you saw this review request (are you set up with an account on phabricator.services.mozilla.com?)

Comment 3

[Christian Kujau]

Isn't this related to or even a duplicate of bug 829677?

Comment 4

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

They're related but slightly different. This deals with expired entries that we no longer need.

Comment 5

[Kai Engert [:KaiE:]]

(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

Comment 6

[Kai Engert [: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.

Comment 7

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

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

Comment 8

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

Kai, thoughts about comment 7?

Comment 9

[Kai Engert [: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?

Comment 10

[Kai Engert [:KaiE:]]

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.

Comment 11

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

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.

Comment 12

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/projects/nss/rev/fbd5eb8b3fc1

Comment 13

[Kai Engert [:KaiE:]]

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

Comment 14

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

Ah - didn't know that. Follow-up in https://phabricator.services.mozilla.com/D258 (let me know if phabricator isn't working for you)

Comment 15

[Phabricator Automation]

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

Comment 16

[Kai Engert [:KaiE:]]

(In reply to Phabricator Automation from comment #15)
> https://phabricator.services.mozilla.com/D258#6265

https://hg.mozilla.org/projects/nss/rev/c53c780d7fcb6e2fd1f94709f4e145fb614cef68

Comment 17

[Kai Engert [:KaiE:]]

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

Comment 18

[Kathleen Wilson]

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