Closed Bug 1614521 Opened 5 years ago Closed 5 years ago

NSS DigiNotar distrust records do not work for Firefox

Categories

(Toolkit :: Blocklist Policy Requests, defect, P1)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: keeler, Assigned: jcj)

Details

Attachments

(3 files, 1 obsolete file)

New exceptions v2
1.73 KB, application/json
keeler
: feedback+
Details
revocations.txt
59.36 KB, text/plain
kathleen.a.wilson
: feedback+
Details
BugData.txt
715 bytes, text/plain
keeler
: feedback+
kathleen.a.wilson
: feedback+
Details

It took me a few years, but I finally think I understand bug 829677 comment 10. NSS has certificate and distrust records for two DigiNotar certificates that do not match the real certificates they correspond to (their serial numbers and validity periods are different). Since NSS doesn't do backtracking during certificate path building, this is thought to be sufficient. However, Firefox does do backtracking, so these distrust records would have no effect (they appear to be keyed on issuer an serial number; since the serial numbers are different, looking up the trust for the real certificates won't return the trust records for the stand-in entries).

What if we add them to OneCRL?

Does this problem also affect the other roots that we have used distrust records for?
Trustwave Organization Issuing CA, Level 2 6B49D205
Trustwave Organization Issuing CA, Level 2 6B49D206
TÜRKTRUST Elektronik Sunucu Sertifikası Hizmetleri 827
TÜRKTRUST Elektronik Sunucu Sertifikası Hizmetleri 864

Adding entries for them to OneCRL should address the issue.

The other distrusted roots should work (i.e. they're distrusted) because those entries (should) use to the real serial numbers.

Just brainstorming on how to approach this... We could, "for consistency", add all of the actively distrusted certs to OneCRL (that are not already in OneCRL).

I think that would be:
Issuer Serial
DigiNotar Root CA 0c76da9c910c4e2c9efe15d058933c4c #not after 2025-03-31 -- root
DigiNotar PKIoverheid CA Organisatie - G2 -- Is it sufficient to just add the root to OneCRL?
Trustwave Organization Issuing CA, Level 2 6B49D206 # Not After : Apr 4 15:37:15 2021 GMT, Bug 724929
TÜRKTRUST Elektronik Sunucu Sertifikası Hizmetleri 827 # Not Valid After : Tue Jul 06 07:07:51 2021, Bug 825022
TÜRKTRUST Elektronik Sunucu Sertifikası Hizmetleri 864 # Not Valid After : Thu Aug 05 07:07:51 2021, Bug 825022

Notes:
https://bugzilla.mozilla.org/show_bug.cgi?id=431621 - DigiNotar Root Inclusion Bug
https://tls-observatory.services.mozilla.com/static/certsplainer.html?id=473485 -- DigiNotar Root

Fascinating situation; I honestly would have expected these to be in OneCRL already.

I recommend we add them all, intermediates as well as roots, to OneCRL. The roots should be sufficient, but our intention was to utterly remove trust with the knock-out entry anyway, so prohibiting the intermediates explicitly keeps them from having trust bits set themselves.

In one of the original DigiNotar distrust bugs, there's mention of cross-signs for the intermediate, so we should include it.

I can build this OneCRL addition tomorrow; I can't get it done today.

Assignee: nobody → jjones
Group: crypto-core-security → firefox-core-security
Component: CA Certificates Code → Blocklist Policy Requests
Priority: -- → P1
Product: NSS → Toolkit
QA Contact: jjones
Version: trunk → unspecified

Auditing the certdata.txt, we these are the distrust entries which haven't expired yet (3 Egypt Trust CAs expired in 2018)

# Certificate "Explicitly Distrust DigiNotar Root CA"
#
# Issuer: E=info@diginotar.nl,CN=DigiNotar Root CA,O=DigiNotar,C=NL
# Serial Number:0f:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
# Subject: E=info@diginotar.nl,CN=DigiNotar Root CA,O=DigiNotar,C=NL
# Not Valid Before: Fri Jul 27 17:19:37 2007
# Not Valid After : Mon Mar 31 18:19:22 2025
# Fingerprint (MD5): 0A:A4:D5:CC:BA:B4:FB:A3:59:E3:E6:01:DD:53:D9:4E
# Fingerprint (SHA1): C1:77:CB:4B:E0:B4:26:8E:F5:C7:CF:45:99:22:B9:B0:CE:BA:21:2F

(all same pubkey)
https://crt.sh/?id=2370015214
https://crt.sh/?id=2370015129
https://crt.sh/?id=2369896934

to be added to OneCRL, by subject and public key



# Certificate "Explicitly Distrusted DigiNotar PKIoverheid G2"
#
# Issuer: CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNotar B.V.,C=NL
# Serial Number: 268435455 (0xfffffff)
# Subject: CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNotar B.V.,C=NL
# Not Valid Before: Wed May 12 08:51:39 2010
# Not Valid After : Mon Mar 23 09:50:05 2020
# Fingerprint (MD5): 2E:61:A2:D1:78:CE:EE:BF:59:33:B0:23:14:0F:94:1C
# Fingerprint (SHA1): D5:F2:57:A9:BF:2D:D0:3F:8B:46:57:F9:2B:C9:A4:C6:92:E1:42:42

https://crt.sh/?id=1841320

to be added to OneCRL, by issuer and serial number



# Explicitly Distrust "MITM subCA 1 issued by Trustwave", Bug 724929
# Issuer: E=ca@trustwave.com,CN="Trustwave Organization Issuing CA, Level 2",O="Trustwave Holdings, Inc.",L=Chicago,ST=Illinois,C=US
# Serial Number: 1800000005 (0x6b49d205)
# Not Before: Apr  7 15:37:15 2011 GMT
# Not After : Apr  4 15:37:15 2021 GMT

https://crt.sh/?id=95565
Revoked already in OneCRL



# Explicitly Distrust "MITM subCA 2 issued by Trustwave", Bug 724929
# Issuer: E=ca@trustwave.com,CN="Trustwave Organization Issuing CA, Level 2",O="Trustwave Holdings, Inc.",L=Chicago,ST=Illinois,C=US
# Serial Number: 1800000006 (0x6b49d206)
# Not Before: Apr 18 21:09:30 2011 GMT
# Not After : Apr 15 21:09:30 2021 GMT

https://crt.sh/?id=95565
Revoked already in OneCRL



# Explicitly Distrust "TURKTRUST Mis-issued Intermediate CA 1", Bug 825022
# Issuer: O=T..RKTRUST Bilgi ..leti..im ve Bili..im G..venli..i Hizmetleri A...,C=TR,CN=T..RKTRUST Elektronik Sunucu Sertifikas.. Hizmetleri
# Serial Number: 2087 (0x827)
# Subject: CN=*.EGO.GOV.TR,OU=EGO BILGI ISLEM,O=EGO,L=ANKARA,ST=ANKARA,C=TR
# Not Valid Before: Mon Aug 08 07:07:51 2011
# Not Valid After : Tue Jul 06 07:07:51 2021
# Fingerprint (MD5): F8:F5:25:FF:0C:31:CF:85:E1:0C:86:17:C1:CE:1F:8E
# Fingerprint (SHA1): C6:9F:28:C8:25:13:9E:65:A6:46:C4:34:AC:A5:A1:D2:00:29:5D:B1

http://crt.sh/?id=12624995

to be added to OneCRL, by issuer and serial number



# Explicitly Distrust "TURKTRUST Mis-issued Intermediate CA 2", Bug 825022
# Issuer: O=T..RKTRUST Bilgi ..leti..im ve Bili..im G..venli..i Hizmetleri A...,C=TR,CN=T..RKTRUST Elektronik Sunucu Sertifikas.. Hizmetleri
# Serial Number: 2148 (0x864)
# Subject: E=ileti@kktcmerkezbankasi.org,CN=e-islem.kktcmerkezbankasi.org,O=KKTC Merkez Bankasi,L=Lefkosa,ST=Lefkosa,C=TR
# Not Valid Before: Mon Aug 08 07:07:51 2011
# Not Valid After : Thu Aug 05 07:07:51 2021
# Fingerprint (MD5): BF:C3:EC:AD:0F:42:4F:B4:B5:38:DB:35:BF:AD:84:A2
# Fingerprint (SHA1): F9:2B:E5:26:6C:C0:5D:B2:DC:0D:C3:F2:DC:74:E0:2D:EF:D9:49:CB

https://crt.sh/?id=12722118

to be added to OneCRL, by issuer and serial number```
Attached file New exceptions (JSON) (obsolete) —
Comment on attachment 9126162 [details] New exceptions (JSON) Dana, can you review this for sanity re: the previous comment, particularly double-check my pubKeyHash work? After that I'll run the Salesforce tooling and produce the public bug for Kathleen to review as well.
Attachment #9126162 - Flags: feedback?(dkeeler)

(In reply to J.C. Jones [:jcj] (he/him) from comment #7)

Certificate "Explicitly Distrusted DigiNotar PKIoverheid G2"

Issuer: CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNotar B.V.,C=NL
Serial Number: 268435455 (0xfffffff)
Subject: CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNotar B.V.,C=NL
Not Valid Before: Wed May 12 08:51:39 2010
Not Valid After : Mon Mar 23 09:50:05 2020
Fingerprint (MD5): 2E:61:A2:D1:78:CE:EE:BF:59:33:B0:23:14:0F:94:1C
Fingerprint (SHA1): D5:F2:57:A9:BF:2D:D0:3F:8B:46:57:F9:2B:C9:A4:C6:92:E1:42:42

https://crt.sh/?id=1841320

to be added to OneCRL, by issuer and serial number

Is it already in OneCRL?
https://crt.sh/?id=1841320 says it is.

Explicitly Distrust "MITM subCA 1 issued by Trustwave", Bug 724929
Issuer: E=ca@trustwave.com,CN="Trustwave Organization Issuing CA, Level 2",O="Trustwave Holdings, Inc.",L=Chicago,ST=Illinois,C=US
Serial Number: 1800000005 (0x6b49d205)
Not Before: Apr 7 15:37:15 2011 GMT
Not After : Apr 4 15:37:15 2021 GMT

https://crt.sh/?id=95565
Revoked already in OneCRL

I think it's this one: https://crt.sh/?id=95566
Serial Number: 1800000005 (0x6b49d205)
It is Revoked already in OneCRL

Explicitly Distrust "MITM subCA 2 issued by Trustwave", Bug 724929
Issuer: E=ca@trustwave.com,CN="Trustwave Organization Issuing CA, Level 2",O="Trustwave Holdings, Inc.",L=Chicago,ST=Illinois,C=US
Serial Number: 1800000006 (0x6b49d206)
Not Before: Apr 18 21:09:30 2011 GMT
Not After : Apr 15 21:09:30 2021 GMT

https://crt.sh/?id=95565
Revoked already in OneCRL

Is that the same cert as the one in certdata.txt?
(different serial number)

Wow. Sorry for all that big, bold text. It didn't look that way when I entered it. :-(
Looks like removing the #'s fixed it.

I get distracted by one meeting in between this and I botched ... more than half of the data.

So you're right of course - DigiNotar PKIoverheid CA Organisatie - G2 is already in OneCRL.

Also, TrustWave serial 1800000006 is not in OneCRL; 1800000005 is, via manual inspection. The 1800000005 serial encodes to base64 as a0nSBQ==, while 1800000006 = a0nSBg==, and only the one appears in OneCRL.

1800000006 doesn't appear in crt.sh, I need to track it down.

Per https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c86 and the surrounding comments, I'm guessing we have no copy of the re-issued 1800000006, so I'll have to construct the block by hand, or switch to subject/public-key.

(In reply to J.C. Jones [:jcj] (he/him) from comment #13)

Per https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c86 and the surrounding comments, I'm guessing we have no copy of the re-issued 1800000006, so I'll have to construct the block by hand, or switch to subject/public-key.

Thinking about this some more, we probably don't need to worry about the TrustWave certs, because their Issuer was revoked and added to OneCRL.
I think their issuer is: https://crt.sh/?id=95565

Agreed.

So that leaves us with the Turktrust and the one DigiNotar Root CA. I'll update the attachment here.

Attached file New exceptions v2 —
Attachment #9126162 - Attachment is obsolete: true
Attachment #9126162 - Flags: feedback?(dkeeler)
Attached file revocations.txt —
Attachment #9126256 - Flags: feedback?(kwilson)
Attached file BugData.txt —
Attachment #9126257 - Flags: feedback?(kwilson)
Attachment #9126257 - Flags: feedback?(dkeeler)
Attachment #9126257 - Flags: feedback?(dkeeler) → feedback+
Comment on attachment 9126257 [details] BugData.txt Looks good to me, but the https://mozkeeler.github.io/blocklister/index.html tool that I use to decode these entries doesn't handle the "subject and public key" entry.
Attachment #9126257 - Flags: feedback?(kwilson) → feedback+
Comment on attachment 9126256 [details] revocations.txt I don't think we need TLS Canary run, so this attachment might not be needed. I visually inspected it and found that the 3 new entries were added. The tools that I usually use to check revocations.txt do not handle the "subject and public key" entry. (onecrl2csv.go and the tool that Chris provided that compares revocations.txt against cert_storage and CCADB)
Attachment #9126256 - Flags: feedback?(kwilson) → feedback+

After thinking about this some more, this must be the first time we are adding a "subject and public key" entry to OneCRL, so it's possible that the tools I use won't be the only thing that breaks...

Perhaps we should run TLS Canary on this version of revocations.txt to make sure it will all work as expected?

Flags: needinfo?(jjones)

We don't actually know if the DigiNotal root itself was compromised, or what certs were produced (other than a handful detected by Google). Users were protected for a while, but if whoever got the certs held on to them past that point (and who throws digital things away?) they would have been potentially used against Firefox and Tor Browser folks. I think we do need an advisory for this. Not sure how to rate this. Sec-high if the bug was actually used? sec-moderate because it doesn't seem too likely someone would think to try again after it failing for years and still failing in other browsers?

Had to patch kinto-blacklist-entry-checker to support subject/pubKeyHash OneCRL entries.

Worked, downloaded 1146 entries from the staging list.

Evaluating expected file = '/tmp/BugData.txt'

Results:
Pending Kinto Dataset (Found): 1146
Added Entries (Expected): 3
[GOOD] Expected But Not Pending (Not Found): 0
Deleted: 0
[GOOD] Entries In Production But Lost Without Being Deleted (Missing): 0

[GOOD] The Expected file matches the change between the staged Kinto and production.
[GOOD] The Kinto dataset found at production equals the union of the expected file and the live list.
Nothing not found.
Nothing deleted.

I will test Firefox with the revocations file next.

Selena, we're thinking of issuing an advisory for this, but we wanted to check in with you first. What are your thoughts?

Flags: needinfo?(sdeckelmann)

Wennie, same question - we're thinking of issuing an advisory for this, but we wanted to check in with you first. What are your thoughts?

Flags: needinfo?(wleung)

I've verified the subject/pubKeyHash loads correctly:

Using Firefox 73, I copied the attached revocations.txt into the profile directory and restarted (to avoid remembering the sync-override commands).

I enabled the browser console, then in the browser console ran:

const certList = Cc["@mozilla.org/security/certblocklist;1"].getService(
        Ci.nsICertBlocklist
      );


// issuer: MIGsMT0wOwYDVQQDDDRUw5xSS1RSVVNUIEVsZWt0cm9uaWsgU3VudWN1IFNlcnRpZmlrYXPEsSBIaXptZXRsZXJpMQswCQYDVQQGEwJUUjFeMFwGA1UECgxVVMOcUktUUlVTVCBCaWxnaSDEsGxldGnFn2ltIHZlIEJpbGnFn2ltIEfDvHZlbmxpxJ9pIEhpem1ldGxlcmkgQS7Fni4gKGMpIEthc8SxbSAgMjAwNQ== serial: CCc=

certList.isCertRevoked("MIGsMT0wOwYDVQQDDDRUw5xSS1RSVVNUIEVsZWt0cm9uaWsgU3VudWN1IFNlcnRpZmlrYXPEsSBIaXptZXRsZXJpMQswCQYDVQQGEwJUUjFeMFwGA1UECgxVVMOcUktUUlVTVCBCaWxnaSDEsGxldGnFn2ltIHZlIEJpbGnFn2ltIEfDvHZlbmxpxJ9pIEhpem1ldGxlcmkgQS7Fni4gKGMpIEthc8SxbSAgMjAwNQ==", "CCc=", "", "");

// issuer: MIGsMT0wOwYDVQQDDDRUw5xSS1RSVVNUIEVsZWt0cm9uaWsgU3VudWN1IFNlcnRpZmlrYXPEsSBIaXptZXRsZXJpMQswCQYDVQQGEwJUUjFeMFwGA1UECgxVVMOcUktUUlVTVCBCaWxnaSDEsGxldGnFn2ltIHZlIEJpbGnFn2ltIEfDvHZlbmxpxJ9pIEhpem1ldGxlcmkgQS7Fni4gKGMpIEthc8SxbSAgMjAwNQ== serial: CGQ=

certList.isCertRevoked("MIGsMT0wOwYDVQQDDDRUw5xSS1RSVVNUIEVsZWt0cm9uaWsgU3VudWN1IFNlcnRpZmlrYXPEsSBIaXptZXRsZXJpMQswCQYDVQQGEwJUUjFeMFwGA1UECgxVVMOcUktUUlVTVCBCaWxnaSDEsGxldGnFn2ltIHZlIEJpbGnFn2ltIEfDvHZlbmxpxJ9pIEhpem1ldGxlcmkgQS7Fni4gKGMpIEthc8SxbSAgMjAwNQ==", "CGQ=", "", "");


// subject: MF8xCzAJBgNVBAYTAk5MMRIwEAYDVQQKEwlEaWdpTm90YXIxGjAYBgNVBAMTEURpZ2lOb3RhciBSb290IENBMSAwHgYJKoZIhvcNAQkBFhFpbmZvQGRpZ2lub3Rhci5ubA== pubKeyHash: qQOvjAe7kbDZ4/OjDG1TM5/FvUfl1r20dlmIYMBooCQ=
// to get the whole pubKey, not just the hash, download the cert:
// curl --silent https://crt.sh/?d=2370015214 > /tmp/2370015214.pem
// then
// openssl x509 -text -in /tmp/2370015214.pem -pubkey
// and pull the b64 pubkey data here
let pubKey = "MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEArLBYwQC92CEICyua/m5WMAWfG3eQEEFcww2HEXeOgfHKfOmMau04dDW72t/5u8AJN7SWc4F9MxqYOfeTb5V/PbmxdYe6UUjoi3A+lQTF2LbDFtmIsLGHHXDahrQPFIt6zxDRdDaiEnt3hkp55nvfAhFopU6GrjRYmyQTeFYiJR4Bi0tRcfuCzFmWaYhaaFPFuQ0CN8tLvGZKkH4qCwUH7RZfVZB12EbJG4PiCL7xI8yZHdYqD4MgFVgngi764iLCSbG5AYFqnW2dQHdodk4hKm2EQIVOdpl8gvPztwJZ1CYBG47frVMG0a4Y3eKyOsvXiDiOrFspuRnTmPkYA89IgoZmCxtpD8nrOIh6JhoFTJLXJNSW8qxSLaNH1VL2P/7OhAZwpqo+ovK2VjQYV6LkgW3nyvBq08eRawKDQXwV72uaZF7j0Dzlset7XYb7y+Z3Sc2jZdz3uZy45Atfk8/MMBoyHM4cY5Wl+erhdIue6SupMHugGB8OGAvlW6nT0WweB2ePkUupirzSZqqTAYiykfoxXNWmwVIICc0KY6LTIqboodk5Bpf1bo0CkIwUez+AzRucusRYciOvtlafxnpCMykHP4LJ5h8FDc1MKDaL08g+HMaI717uiWTpHevaiX4ypmnR3cyIn9HQyWYh3AZnxZR6mm1iTH3M4GSAsp5HjqMCAwEAAQ==";
let subject = "MF8xCzAJBgNVBAYTAk5MMRIwEAYDVQQKEwlEaWdpTm90YXIxGjAYBgNVBAMTEURpZ2lOb3RhciBSb290IENBMSAwHgYJKoZIhvcNAQkBFhFpbmZvQGRpZ2lub3Rhci5ubA==";

certList.isCertRevoked("", "", subject, pubKey);

all returned true

Flags: needinfo?(jjones)

The entries are ready at Kinto, and I manually verified Firefox 73. Again, we have automated tests of subject/public-key blocks, even though we haven't used one in production before.

I think we're ready to sign and push the entry at any time. Since I constructed the entry at Kinto, I cannot provide sign-off. Actually performing the block I think should be done as soon as practical, without needing resolution about an advisory.

(In reply to J.C. Jones [:jcj] (he/him) from comment #27)

I think we're ready to sign and push the entry at any time. Since I constructed the entry at Kinto, I cannot provide sign-off. Actually performing the block I think should be done as soon as practical, without needing resolution about an advisory.

I agree. Even if we decide to issue an advisory, I think we should make sure that OneCRL has been updated first.

Dana, can you approve the changes in Kinto? (I let my access lapse while Wayne was here)

Dana has signed the changes and they're live.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Flags: needinfo?(sdeckelmann)

I spoke with Selena and I'm drafting a document that explains the necessary background, the timeline of events, who was affected by this issue, etc., so we can have the information necessary to make a determination on an advisory.

Flags: needinfo?(wleung)
Group: firefox-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: