Exciting Updates to Certificate Verification in Gecko

cviecco

9

Today we’re excited to announce a new certificate verification library for Mozilla Products – mozilla::pkix! While most users will not notice a difference, the new library is more robust and maintainable. The new code is more robust because certificate path building attempts all potential trust chains for a certificate before giving up (acknowledging the fact that the certificate space is a cyclic directed graph and not a forest). The new implementation is also more maintainable, with only 4,167 lines of C++ code compared to the previous 81,865 lines of code which had been auto-translated from Java to C. The new library benefits from C++ functionality such as memory cleanup tools (e.g., RAII).

To provide some more background, Gecko has historically used the certificate verification processing in NSS to ensure that the certificates presented during a TLS/SSL handshake is valid. NSS currently has two code paths for doing certificate verification: “classic” used by Gecko for Domain Validated (DV) certificate verification, and libPKIX used by Gecko for Extended Validation (EV) certificate verification. The NSS team has wanted to replace the “classic” verification with libPKIX for some time because libPKIX handles cross-signed certificates better and properly handles certificate policies required for Enhanced Validation (EV) certificates. However, libPKIX has proven to be very difficult to work with.

We also took the opportunity to enforce some requirements in Mozilla’s CA Certificate Policy and in the CA/Browser Forum’s Baseline Requirements (BRs). The changes are listed here. While we have performed extensive compatibility testing, it is possible that your website certificate will no longer validate with Firefox 31. This should not be a problem if you use a certificate issued by one of the CAs in Mozilla’s CA Program, because they should already be issuing certificates according to Mozilla’s CA Certificate Policy and the BRs. If you notice an issue due to any of these changes, please let us know.

We are looking for feedback with respect to compatibility and security. For compatibility, we ask all site operators and security testers to install Firefox 31 and use it to browse to your favorite sites. In addition, we ask for willing C++ programmers out there to review our code. This new mozilla::pkix library is located at security/pkix and security/certverifier. A more detailed description is here. If you find an issue, please help us make it better by filing a Bugzilla bug report.

We look forward to your feedback on this new certificate verification library.

Mozilla Security Engineering Team

9 responses

  1. BoerenkoolMetWorst wrote on :

    “and does not require that issuer’s subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. ”
    Doesn’t this decrease security?

    1. cviecco wrote on :

      Removing this restriction does not decrease security. Lets assume an attacker is able to modify this field at will in a way that the signature of the certificate is still valid (assume the AKI was not part of the signed structure).
      Can he/she gain use this new certificate to access new privileges? – NO
      Can he/she issue new certificates with extra capabilities? – NO
      Can he/she impersonate other entities? – NO

      The primary purpose of the AKI field is to help verification libraries that are not able to follow the graph structure to decide which is the correct signer of a certificate when its certificate store contains more than one CA certificate with the same subject name. Since we are now able to do a graph search, this field is just an optimization.

      1. BoerenkoolMetWorst wrote on :

        Thanks for your reply.

        I hope Mozilla will also give high priority to other verification related standards such as OCSP-must-staple, DNSSEC/DANE and Certificate pinning.

        1. cviecco wrote on :

          We are actively working on Certificate Pinning and have some interest on OCSP-must-staple. DNSSEC/DANE is not on our immediate priority list.

  2. ralf wrote on :

    Please remove all CA from Firefox by default. CA should be about trust and this Trust was abused by too much CA already.

  3. Marc Brooks wrote on ::

    First bug, you’re returning Success from the CheckKeyUsage function after declaring this code ready for security analysis. That’s just asking for someone to use this source before you get around actually getting around to checking key usage.

    If you’re not done, DON’T PRETEND IT IS, return an error.

    1. cviecco wrote on :

      If you think you have found a bug, please file it. If it is a regression (compared to NSS) you might be able to claim the special mozilla bounty for this code https://blog.mozilla.org/security/2014/04/24/10000-security-bug-bounty-for-certificate-verification/.

  4. Ian wrote on :

    Will this support the DANE trust model?

    1. cviecco wrote on :

      We are not exploring this at this moment.