SecurityEngineering/mozpkix-testing: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 8: Line 8:
== Request for Testing ==
== Request for Testing ==


Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people test it as possible. So we ask that all of you help us test this new library as follows.
Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. So we ask that all of you help us test this new library as follows.


# Download Firefox 31 or later
# Download Firefox 31 or later

Revision as of 18:55, 7 April 2014

mozilla::pkix

Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, OCSP, PKIX, and other security standards.

NSS currently has two code paths for doing certificate verification. "Classic" verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates.

As many of you are aware, the NSS team has wanted to replace the "classic" verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix.

Request for Testing

Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. So we ask that all of you help us test this new library as follows.

  1. Download Firefox 31 or later
    • Browse to ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/
    • Scroll down to mozilla-central-<platform>-debug and select the folder that matches the platform you are working on.
    • Select the most recent build in the list.
    • Download by selecting the .tar.bz2 (Linux), .dmg (Mac), or .exe (Windows) file.
    • After downloading, extract and run this debug browser, which will be called FirefoxNightlyDebug.
  2. mozilla::pkix should be enabled by default. Ensure that it is by doing the following:
    • Open about:config in Firefox
    • Locate the preference "security.use_mozillapkix_verification"
    • If it is true, nothing more needs to be done
    • If it is false, set it to true
    • If it is not present, update to a more recent FirefoxNightlyDebug build
    • Clear your browser cache if you are going to browse to a site you visited with mozilla::pkix off
  3. Browse to various websites with known valid and expired/revoked/etc SSL certificates.
  4. If you don't get the expected result, then try again without using mozilla::pkix to see if the unexpected result is actually due to mozilla::pkix.
    • In about:config toggle "security.use_mozillapkix_verification" to false
      • Or switch to a previously released version of Firefox
    • Clear your browser cache if you are going to browse to a site you visited with mozilla::pkix on
  5. If you find an issue, please file a Bugzilla bug (https://bugzilla.mozilla.org/enter_bug.cgi) with Product=Core, Component=Security:PSM, and put "(mozilla::pkix)" at the beginning of the Summary.

Request for Code Review

We will greatly appreciate your help in reviewing the new code, which may be found here:

Coming Soon: High level description of the folders/files/classes

If you find an issue, please file a Bugzilla bug (https://bugzilla.mozilla.org/enter_bug.cgi) with Product=Core, Component=Security:PSM, and put "(mozilla::pkix)" at the beginning of the Summary.

For reference, the NSS certificate verification code is here:

What To Report

We are especially interested in finding errors that cause the following to happen:

  1. SSL connections succeed when they should fail, and they did fail in previous releases.
  2. EV treatment is given when it should not be given, and was not being given in previous releases.
  3. An SSL connection fails when it should have succeeded.
  4. EV treatment is not given when it should be.
  5. An SSL connection gives a different error than expected.
  6. SSL connections succeed when they should fail, and they did not fail in previous releases. Note that this could be due to not enforcing certain standards, and may be a policy decision.
  7. EV treatment is given when it should not be given and was being given in previous releases. Note that this could be due to not enforcing certain standards, and may be a policy decision.
  8. Code Signing certificates do not work as expected.

Mozilla::pkix Bug list

Things for CAs to Fix

Workarounds were implemented to allow mozilla::pkix to handle the following situations. We will be asking CAs to immediately stop issuing new certificates with these issues, and we will identify dates for removing these workarounds.

  1. Stop using the "Netscape Server Gated Crypto (2.16.840.1.113730.4.1)" (SGC) EKU. For all new certificate issuance, use the "TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)" EKU instead of the SGC EKU.
  2. Default values in a SEQUENCE must not be explicitly encoded. We found end-entity certificates that have the value cA:false explicitly encoded.
    • 11.5 of X.690 - "The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value."
    • Related Bugs: bug 988633, bug 989516, bug 989518
  3. Basic constraints: pathLenConstraint must not be included if cA is false
    • RFC 5280 section 4.2.1.9: "CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit."
    • Related Bugs: bug 982878, bug 985021, bug 985025

Future Considerations

While testing mozilla::pkix, we noticed the following things that we would like to consider changing.

  1. Consider only giving EV treatment when the intermediate and end-entity certs in the chain have the specific EV policy OID that we are expecting; in other words, don’t give EV treatment when the intermediate certificate has the anyPolicy OID. To make this change, would need to change the CAB Forum’s EV Guidelines to also require the EV policy OID in intermediate certs (section 9.3.4 says the subordinate CA certificate may contain anyPolicy OID 2.5.29.32.0).
Retrieved from "https://wiki.allizom.org/index.php?title=SecurityEngineering/mozpkix-testing&oldid=961737"