Closed Bug 683261 Opened 13 years ago Closed 13 years ago

Better coverage for DigiNotarGate in NSS

Categories

(NSS :: Libraries, defect)

3.12.11
defect
Not set
normal

Tracking

(firefox6 .2-fixed, firefox7 fixed, firefox8 fixed, firefox9 fixed, status1.9.2 .22-fixed)

VERIFIED FIXED
Tracking Status
firefox6 --- .2-fixed
firefox7 --- fixed
firefox8 --- fixed
firefox9 --- fixed
status1.9.2 --- .22-fixed

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

(Keywords: verified-beta, verified1.9.2, Whiteboard: [qa+])

Attachments

(7 files, 4 obsolete files)

4.44 KB, application/octet-stream
Details
31.04 KB, patch
rrelyea
: review+
Details | Diff | Splinter Review
35.33 KB, application/octet-stream
Details
30.95 KB, patch
Details | Diff | Splinter Review
20.11 KB, application/octet-stream
Details
17.85 KB, patch
rrelyea
: review+
Details | Diff | Splinter Review
17.79 KB, patch
Details | Diff | Splinter Review
      No description provided.
This is a follow-up to 682927.

Let's use this bug to add overriding blocker certs to NSS.
Depends on: 682927
Please see bug 682927 comment 82 to 84 for the initial TODO list for this one.

I can do the testing that Bob suggested in comment 84, but I'm quite exhausted already for today.

Also, Bob suggested that we should include two additional intermediate certs.
This means,
I propose we do a
  NSS_BUILTINS_LIBRARY_VERSION "1.85"

that overrides (at least) three certs - the root, and two intermediates.

Also, the blocker cert that I had added to bug 683261 might be insufficient.
Bob suggested I must make that one "newer" than all intermediates we want to override.
Haven't checked that yet.

Also, regarding serial numbers, I probably must keep track of the serial numbers we use for the blocker certs, and avoid duplicates.

For the root blocker cert I had used 0x0fffffffffffffff as the serial number.
Hold on. Updated information. Let me rework comment 2 and comment 3.
i2

Issuer: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority
Validity
  Not Before: Jul 26 15:59:00 2007 GMT
  Not After : Aug 26 16:29:00 2013 GMT
Subject: C=NL, O=DigiNotar, CN=DigiNotar Services 1024 CA/emailAddress=info@diginotar.nl


i3

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
Validity
  Not Before: Oct  4 10:54:11 2006 GMT
  Not After : Oct  4 10:53:11 2011 GMT
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA/emailAddress=info@diginotar.nl
marking comments 3 and 4 as private, to reduce confusion.
(a) + (b)
Which serial numbers should I use for the blocker certs?

Is it necessary to ask Entrust and GTE Corporation to assign a serial number for us, so we don't have collisions with other valid Entrust/GTE certs?


(c)
Bob, you're saying, the blocker cert for the "DigiNotar Root CA" should have a "Not Before" that's in the future of both i2 and i3 ?
Kai: using 0x0fffffffffffffff, 0x0ffffffffffffffe,
0x0ffffffffffffffd, etc. as serial numbers should
be unlikely to conflict with serial numbers of real
certificates.
Kai: in certdata.txt, you added
  "Explicity Disable DigiNotar Root CA"

Please change the first two words to "Explicitly Distrusted".
Note that "Explicitly" was misspelled.
We may want to do 683455 as part of this bug.
I plan to block multiple certificates at the NSS level.

Note, this approach ensures the basic (potentially overridable) blocking is "at least complete".

By "at least complete" I mean, it includes all of SSL, S/MIME, code signing.
The patch for PSM that we did yesterday covers SSL, only.

Because yesterday we also removed trust for the root, this also covers parts of S/MIME and code signing, but only those chains that use the root.

Because of the cross signing from other CAs, yesterday's solution was not complete.
Attached file zip file - collection of certs (obsolete) —
This is a collection of zip files that I have created.

It includes 3 certs - but it covers 5 certs.

For each of the original 3 certs, it also includes an override cert, which I have manually edited, to use a new serial number and have special validity.
addbuiltin -n "Explicitly Distrust DigiNotar Root CA" -t ,, < ~/moz/nss/head/diginotar/im/Root-DigiNotarRootCA-override.der  >> certdata.txt

addbuiltin -n "Explicitly Distrust DigiNotar Services 1024 CA" -t ,, < ~/moz/nss/head/diginotar/im/A-override-DigiNotarServices1024CA.der  >> certdata.txt

addbuiltin -n "Explicitly Distrust DigiNotar Cyber CA" -t ,, < ~/moz/nss/head/diginotar/im/B-override-real-cyberca.der  >> certdata.txt
not yet tested. I will test it in approx. 1 to 1.5 hours.
Kai: can we open this bug, now the others are open?

Gerv
(In reply to Gervase Markham [:gerv] from comment #15)
> Kai: can we open this bug, now the others are open?

fine with me
Group: core-security
(branch patch is good - updating bad trunk patch)
Attachment #557212 - Attachment is obsolete: true
Kai, The DigiNotar Root interference cert needs a different issuance date: I needs to ble later than Jul 26, 2007, or more specifically later than "070726155739Z" (Thu Jul 26 15:57:39 2007) so 070726155740Z would be sufficient.

bob
Never mind, I was looking at the original root cert, not the interference/override cert. The override cert looks good! I'll go review the patches now...

bob
FYI, update:

During testing, we learned that these override certs cause blocking - but too much blocking - it's no longer possible to override certs.

We understand you're not happy with this. We understand, you want that we still have overridable soft-blocking.

Because of this, Genius Bob Relyea came up with another idea. He does additional manipulation to the intermediate certs - causing them to look like self signed certs.

Bob just gave me the first cert - and it works.

What does this mean?

- we'll shortly have a new patch

- Bob must do some tricky binary editing, calculating, shortening/extended file sizes, and adjusting encoding lengths in multiple layers

- Bob will have to do this tricky work for each of the additional intermediates that need to be blocked
Per Kathleen's request, I attach a zip containing three cross certificates issued under the GTE CyberTrust Global Root presently managed by Verizon.  Within the next hour, we will revoke these cross certificates and post a new CRL.

These cross certificates were provided under contract to DigiNotar to provide legacy browser support as DigiNotar's root gained its own independent ubiquity.  One of these cross certificates has life until September of 2013, and two will expire within weeks.

While DigiNotar no longer distributes these cross certificates, they once did and therefore these are to be considered easily accessible as a method of bypassing revocation and blacklisting of the DigiNotar root.  We have researched and concluded that these alternate paths to unauthorized trust would perpetuate the issues that led to the actions of the past two days and are a threat to the trust of our GTE CyberTrust Global Root PKI and therefore must be revoked.
Ok. We already had the 100406 certs in our list (it's contained in my earlier zip file, named B-real-cyberca.der

We will add the additional two roots - 092006 and 092706

It would be nice if we could have test sites for all 3 certs.
(If you don't want to mention them in the public, please send them to me by private email, and I'll keep the lists confidential amongst testers.)
Test EE cert information and chains on operational servers would need to come from DigiNotar.  It is possible that DigiNotar do not currently operate any test sites that chain through these any longer.  Our cross certificates are not documented at their PKI hierarchy page, http://www.diginotar.nl/Klantenservice/Rootcertificaten/tabid/308/Default.aspx.  We are also absent at their history page as well, where one of our peers does appear.
Bob is away for a couple of hours, so I'm trying to do it myself.
Looking at what Bob did in detail, I am able to repeat the procedure for the additional two certs. I already succeded with the first, now doing the second one, so I should have a new patch within 30 minutes.
Blocks: 683455
CRL reflecting revocations posted to proper CRL DP referenced within the certificates, at:

http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl
The certs with serial numbers 092006 and 092706 have the same subject name.
We can used a single special cert that overrides both.
Assignee: nobody → kaie
Attachment #557183 - Attachment is obsolete: true
Attachment #557219 - Attachment is obsolete: true
Attachment #557179 - Attachment is obsolete: true
Attachment #557315 - Attachment description: zip file collection used for patch v3 → zip file, collection of certs used for patch v3
Attachment #557313 - Flags: review?(rrelyea)
Bob, the "Root" cert is the "DigiNotar Root CA", we had that already.

The A and B certs are the one that you had created.
(B is one of the additional 3 certs from Verizon)

E and F are the two additional certs from Verizon.
Inside the zip file, you'll find E and F certs in the directory "invididual-E-F".

I had manually tweaked both certs, in the same way you did.
When you reminded me that one cert will be sufficient, because E and F have the same subject, I created the combined EF file.

The EF files uses the newest NotBefore + 1 second, and the newest NotAfter + 1 second.
I built mozilla-beta using this patch.

Testing I have performed:

(root)
Visiting
  https://www.evssl.nl
which chains up to DigiNotar Root CA,
I get "untrusted", and I am still able to add an override.

This proofs, our blocker cert for the root doesn't disable the override capability.


(intermediates)
Visiting
  https://www.csnad.nl/
which chains up to DigiNotar Services 1024 CA.
I get "untrusted", and I'm still able to add an override.

This proofs, our blocker certs for the intermediates don't disable the override capability.
Comment on attachment 557313 [details] [diff] [review]
Patch v3 for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH

r+   These binary blobs look correct... (bob looking cross-eyed trying to decode Ascii date codes in octal blobs;).
Attachment #557313 - Flags: review?(rrelyea) → review+
Thanks for the review.
It's very late already at my place, so I will check this in to the stable branch of NSS only, for now.
(I will work on the slightly different patch for NSS trunk tomorrow.)

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.67.2.12; previous revision: 1.67.2.11
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.64.2.12; previous revision: 1.64.2.11
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.24.2.7; previous revision: 1.24.2.6
I've tagged the roots module directory as NSSCKBI_1_86_RTM
(In reply to Kai Engert (:kaie) from comment #33)
> It's very late already at my place, so I will check this in to the stable
> branch of NSS only, for now.
> (I will work on the slightly different patch for NSS trunk tomorrow.)

This is the equivalent for the truink.
I've already checked it in:

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.81; previous revision: 1.80
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.78; previous revision: 1.77
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.31; previous revision: 1.30
done
If we make a further update to this, it would be clearer if the certificate names were of the form:

"Explicitly Distrusted DigiNotar Root CA"

rather than

"Explicitly Distrust DigiNotar Root CA"

The latter is a statement of intent, not a name for something. The former is a name of a certificate.

Gerv
I don't know if this will be needed.
I'm just doing this in order to be prepared - you never know!
I'm asking for a code review.
Will not be checked in unless requested by Mozilla
Attachment #557729 - Flags: review?(rrelyea)
Comment on attachment 557729 [details] [diff] [review]
additional patch v4 - for NSS 3.12.x and stable mozilla branches - MUST RUN "gmake generate" AFTER APPLYING PATCH

r+ This patch removes trust for the PKIoverheid DigiNotar certs. 

I leave it to mozilla policy people to thumbs up or down on applying this patch, but I've verified it's technically correct. It is applied on top of the v3 patch, not in liu of it.

bob
Attachment #557729 - Flags: review?(rrelyea) → review+
Due to the kindness of another CA, I have copies of certs for most DigiNotar chains, and clues as to where to find them. We also have the big list we were using to warn people. The following are live at the time of writing:

Staat der Nederlanden Root CA - G2 via Diginotar PKIOverheid CA Organisatie - G2: 
  https://belastingbalie.eindhoven.nl/ (Issued: 4th Feb 2011)

Staat der Nederlanden Root CA via Diginotar PKIoverheid CA Overheid en Bedrijven:
  https://www.nifpnet.nl/ (Issued 12th May 2011)

GTE CyberTrust Global Root via DigiNotar Cyber CA:
  https://sbc.lodder.com (Issued 27th July 2007)
  (Note: expired 27th July 2011)

Entrust Secure Server Certification Authority via DigiNotar Services 1024 CA:
  https://www.aacweb.nl/ (Issued 23rd April 2008)
  https://acceptation.cbpublications.ingcommercialbanking.com/

DigiNotar Root CA via DigiNotar Services CA:
  https://toegang.eindhoven.nl/ (Issued 25th May 2011)

DigiNotar Root CA via DigiNotar Extended Validation CA:
  https://yob.goestenopdam.nl/ (Issued 13th July 2011)

That last one should be good for testing date-based behaviour.

Gerv
Do we have DigiNotar Public CA 2025 somewhere?
Mike: I have the following info:

DigiNotar Public CA 2025
Serial Number: 1E7D 7A53 3D45 3041 9640 OF71 481F 4504
Validity: Feb 6, 2006 18:07:02 - March 28, 2025 18:07:02
Certificate Fingerprint: 3F01 8E6F E336 096A 791B 81E7 69BE 701A AF21 E307
Intended use: email and personal certificates.

But I don't think I have a copy of the complete cert.

Gerv
(In reply to Mike Hommey [:glandium] from comment #41)
> Do we have DigiNotar Public CA 2025 somewhere?

You can retrieve it from here:

http://www.diginotar.nl/LinkClick.aspx?fileticket=lSCwDq6q038%3d&tabid=308
I've tested my local mozilla-beta build, with
  Bug 683883 (attachment 557592 [details] [diff] [review]) (patch v4 from that bug)
  this bug patch v3 (attachment 557313 [details] [diff] [review])

> Staat der Nederlanden Root CA - G2 via Diginotar PKIOverheid CA Organisatie - G2: 
>  https://belastingbalie.eindhoven.nl/ (Issued: 4th Feb 2011)
> Staat der Nederlanden Root CA via Diginotar PKIoverheid CA Overheid en Bedrijven:
>   https://www.nifpnet.nl/ (Issued 12th May 2011)

both are allowed


>GTE CyberTrust Global Root via DigiNotar Cyber CA:
>  https://sbc.lodder.com (Issued 27th July 2007)
>  (Note: expired 27th July 2011)
>
>Entrust Secure Server Certification Authority via DigiNotar Services 1024 CA:
>  https://www.aacweb.nl/ (Issued 23rd April 2008)
>  https://acceptation.cbpublications.ingcommercialbanking.com/
>
>DigiNotar Root CA via DigiNotar Services CA:
>  https://toegang.eindhoven.nl/ (Issued 25th May 2011)

All 4 sites are treated as "untrusted" with a cert error page.
I open the "add override" dialog, and looked at the chain.
All certs chain up to one of our kock-out certs (detectable, because those certs have a serial numbers like 0x*FFFFFFF

I am able to add overrides for all these certs.


>DigiNotar Root CA via DigiNotar Extended Validation CA:
>  https://yob.goestenopdam.nl/ (Issued 13th July 2011)

I get "cert is revoked", no override possible.
> DigiNotar Public CA 2025 somewhere?
> http://www.diginotar.nl/LinkClick.aspx?fileticket=lSCwDq6q038%3d&tabid=308

This cert chains up to "DigiNotar Root CA", which we already handle, so it should be covered?
We'll wanted this landed everywhere once it is reviewed and tested:

* mozilla-central (default branch)
* releases/mozilla-aurora (default branch)
* releases/mozilla-beta (default branch)
* releases/mozilla-release (default branch)
* releases/mozilla-1.9.2 (default branch)

I can take care of transplanting to whatever relbranches we need. Thanks!
Landing patch v4 into NSS 3.12 branch:

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.67.2.13; previous revision: 1.67.2.12
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.64.2.13; previous revision: 1.64.2.12
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.24.2.8; previous revision: 1.24.2.7
done


Landing patch v4 into NSS trunk:

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.82; previous revision: 1.81
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.79; previous revision: 1.78
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.32; previous revision: 1.31
done
QA would like to verify this behavior prior to signing off, but it's not 100% clear what we should be using as testcases and what the final behavior should be. Any hints would be very appreciated.
See comment #40 - none of those sites should be trusted. I believe the expected behaviour is an overrideable cert_not_trusted error for most of them, but a non-overrideable cert_revoked error for the last one, as it was issued before 1st July 2011.

(You should check, though, that none of the sites has changed their cert since I made that list. This can be seen by looking at the cert chain in the certificate viewer, using a browser without any DigiNotar-related patches.)

Gerv
QA has gone through a list of urls pulled from spreadsheet Gerv had compiled, and we've made sure to verify that the sites in question are not trusted, and we've seen that some of them are not overridable. In a couple of cases, the urls are now trusted because they have updated their certificates.

We verified by checking the URLs in XP using all branches where the problem was fixed, including 3.6.22(build2), 6.0.2(build2), and 7.0b4 (build2).

For good measure, please take a look at the following spreadsheet where we wrote down our results:

https://docs.google.com/spreadsheet/ccc?key=0AnEJ45MnstYjdGVLc0hQV3M0RE1ENDlZOTJqX204ZXc&hl=en_US#gid=0
Verified on latest Nightly on Mac as well.
Status: RESOLVED → VERIFIED
The testing performed by Mike Hommey and me showed that
the explicitly distrusted CA certificates added in this
bug do not work for libpkix.

This problem is important to the NSS team, but probably
can be ignored by Mozilla QA.

Here is the output of the NSS 'vfychain' test program.
By default it uses the "classic" certificate verification
function.  If -pp is specified, it uses CERT_PKIXVerifyCert.
cert.001, cert.002, and cert.003 are the certificate chain
for https://sha2.diginotar.nl/.

$ vfychain -v cert.001 cert.002 cert.003
Chain is bad!
PROBLEM WITH THE CERT CHAIN:
CERT 1. Builtin Object Token:Explicitly Distrusted DigiNotar PKIoverheid G2 [Cer
tificate Authority]:
  ERROR -8171: Peer's certificate has been marked as not trusted by the user.
  ERROR -8179: Peer's Certificate issuer is not recognized.
    CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNotar B.V.,C=NL

$ vfychain -v -pp cert.001 cert.002 cert.003
Chain is good!
Root Certificate Subject:: "CN=Staat der Nederlanden Root CA - G2,O=Staat der
     Nederlanden,C=NL"
Certificate 1 Subject: "CN=sha2.diginotar.nl,serialNumber=0000000334104947000
    0,O=DigiNotar B.V. (0034104947),C=NL"
Certificate 2 Subject: "CN=DigiNotar PKIoverheid CA Organisatie - G2,O=DigiNo
    tar B.V.,C=NL"
Certificate 3 Subject: "CN=Staat der Nederlanden Organisatie CA - G2,O=Staat
    der Nederlanden,C=NL"
FYI: Comment 59 refers to a non-default configuration.
With Bob's patch in bug 642503, and the PKIoverheid G2 cert
(explicitly distrusted) added to certdata.txt, libpkix
correctly rejects the certificate chain:

$ vfychain -v -pp cert.001 cert.002 cert.003
Chain is bad!
PROBLEM WITH THE CERT CHAIN:
CERT 1. Builtin Object Token:Explicitly Distrusted DigiNotar PKIoverheid G2 [Certificate Authority]:
  ERROR -8171: Peer's certificate has been marked as not trusted by the user.
  ERROR -8171: Peer's certificate has been marked as not trusted by the user.

So I will make it a priority to review Bob's patch in bug 642503.
QA tracking; needs verification on Aurora using test in comment 57.
Whiteboard: [qa+]
You need to log in before you can comment on or make changes to this bug.