1. 14 Apr, 2021 1 commit
  2. 23 Jan, 2021 1 commit
  3. 13 Jan, 2021 1 commit
  4. 23 Oct, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1... · 097a456e
      Robert Relyea authored
       Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1 signatures are disabled.
      
      When libpkix is checking an OCSP cert, it can't use the passed in set of trust anchors as a base because only the single root that signed the leaf can sign the OCSP request. As a result it actually checks the signature of the self-signed root when processing an OCSP request. This fails of the root cert signature is invalid for any reason (including it's a sha1 self-signed root cert and we've disabled sha1 signatures (say, by policy)).
      
      Further investigation indicates the difference between our classic code and the current code is the classic code only checks OCSP responses on leaf certs. In the real world, those responses are signed by intermediate certificates (who won't have sha1 signed certificates anymore), so our signature processing works just fine. pkix checks OCSP on the intermediate certificates as well, which are signed by the root cert. In this case the root cert is a chain of 1, and is effectively a leaf. This patch updates the OCSP response code to not check the signatures on the single cert if that cert is a selfsigned root cert. This requires bug 391476 so we still do the other validation checking on the certs (making sure it's trusted as a CA).
      097a456e
  5. 14 Oct, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1670835 Crypto Policy Support needs to be updated with disable/enable support · 7dfc0e17
      Robert Relyea authored
      Policy update
      
      Current state of the nss policy system:
      
      The initial policy patch focused on getting policy working well in handling ssl. The policy infrastructure used two existing NSS infrastructure:
          1) Algorithm policies tied the OIDS and
          2) the ssl policy constraints first created to handle export policy restrictions.
      To make loadable policies work, we added a couple of new things:
         1) a policy parser to the secmod infrastructure which allows us to set algorithm policies based on a config file. This file had two sections: disallow= and allow=. Disallow turned off policy bits, and allow turned them on. Disallow was always parsed first, so you could very strictly control your policy map by saying disallow=all allow={exclusive list of allowed algorithms}
         2) a new NSS_Option() value that allowed the policy parser to set integer values (like minimum tls version) based on the data in the policy parser.
         3) SSL code which is run at ssl_init time that reads the algorithm policies and maps the results to SSL policies.
      
      The resulting loaded policy code, in general, sets the boundaries of what it possible, actually enable/disable of ssl cipher suites are still under program control, and the builtin NSS default values. The only consession to configuration is if a cipher is disallowed by policy, it is also disabled. Allowing a cipher suite by policy that wasn't already enabled, however, doesn't enable that policy by default. Inside the policy restrictions, applications can still make their own decisions on configuration and preference.
      
      At the time the policy system was designed, there were 3 additional features, which were designed, but not specified: disable, enable, and lock.
      
      disable and enable work just like disallow and allow, except the specify what the default settings are. This would allow the policy file to change the underlying default in the case where the application doesn't try to configure ssl on it's own.
      
      lock would make either the policy or configuration 'locked' meaning once the lock has been executed, no further changes to those configurations would be allowed.
      
      What is needed:
      
      We have a need for the following additional features:
      
      1) we want to turn more of the sha-1 hash function off by default. We still need sha-1 digest because it's used in many non-secure cases, but we do want to disable more sha-1 signature usage. Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers can be controlled by policy. We want to disallow a greater range of signature (that is signature use in general).
      
      2) we want to disable more ciphers by default, but need a way to have certain policies (like LEGACY) turn them back on, so that our shipped system is more secure by default.
      
      What this patch provides:
      
      1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The cryptohi code which exports the NSS sign/verify high level code now checks the hash and signing algorithm against this new policy flag and fails if the policy isn't available.
      New key words were added to the policy parser for 'all-signature', which implies all signature flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE. NOTE: disable=all/signature and disable=all/all-signature are effective equivalent because cert-signatures eventually call the low level signature functions, but disable=all allow=rsa-pss/all-signature and disable=all allow=rsa-pss/signature are different in that the latter allows all rsa-pss signature and the latter allows rsa-pss signatures, but no on certificates (or on smime in the future)
      Also new keywords were added for rsa-pkcs, rsa-pss, and ecdsa for signature algorithms (along with dsa).
      
      2) This patch implements disable and enable. These functions only work on SSL configuration. In the future SMIME/CMS configuration could also be added. Because the policy system is parsed and handled by NSS, and SSL configuration is handled in SSL, we use the same Apply code we used to apply ssl policy to set the inital configuration. The configured enable/disable state is configured in the ALGORTHIM policy system, where one bit says the enable/disable value is active and another bit which gives it's state.
      
      3) two locks have been implented, policy-lock and ssl-lock. These are specified in the parser as flags (flags=policy-lock,ssl-lock). The policy locks all the policy changes: ssl_policy, algorithm policy, and options. It is implemented by two new exported functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first allows applications to test if the policy is locked without having to try changing the policy. The various policy set functions check the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK if it's true.
       The ssl-lock changes the state of the policy to locked, and the state cannot be changed back without shutting down NSS. The second is implemented by setting a new Option called NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we can add an SMIME lock in the future. SSL checks the NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite value, and blocks the change if it's set.
      
      4) sslpolicy tests were updated to test the enable, disable, flags=policy-lock, flags=ssl-lock and the new signature primitives.
      
      5) policy tests were updated to be able to run standalone (like all the other all.sh tests), as well as new tests to detect when no signing algorithms have been enabled.
      
      
      What is not in the patch
      
      1) S/MIME signature policy has been defined for a while, but never hooked up.
      2) S/MIME export policy needs to be connected back to the algorithm policy system just like the ssl cipher suites already are.
      3) S/MIME default configuration needs to be connected back to the policy system.
      4) ECC Curve policy  needs to be hooked up with the signature policy (probably should create a generic 'key meets policy' function and have every call it).
      7dfc0e17
  6. 12 Oct, 2020 1 commit
    • Makoto Kato's avatar
      Bug 1657255 - Update CI for aarch64. r=kjacobs · 0504d1c8
      Makoto Kato authored
      Actually, we have the implementation of ARM Crypto extension, so CI is always
      run with this extension. It means that we don't run CI without ARM Crypto
      extension. So I would like to add NoAES and NoSHA for aarch64 CI.
      
      Also, we still run NoSSE4_1 on aarch64 CI, so we shouldn't run this on aarch64
      hardware.
      
      Differential Revision: https://phabricator.services.mozilla.com/D93062
      
      --HG--
      extra : moz-landing-system : lando
      0504d1c8
  7. 19 Aug, 2020 1 commit
  8. 18 Aug, 2020 1 commit
  9. 16 Jul, 2020 1 commit
  10. 29 Jun, 2020 1 commit
  11. 14 Apr, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1629661 MPConfig calls in SSL initializes policy before NSS is initialized. r=mt · 108aa431
      Robert Relyea authored
      NSS has several config functions that multiprocess servers must call before NSS is initialized to set up shared memory caches between the processes. These functions call ssl_init(), which initializes the ssl policy. The ssl policy initialization, however needs to happen after NSS itself is initialized. Doing so before hand causes (in the best case) policy to be ignored by these servers, and crashes (in the worst case).
      
      Instead, these cache functions should just initialize those things it needs (that is the NSPR ssl error codes).
      
      This patch does:
      1) fixes the cache init code to only initialize error codes.
      2) fixes the selfserv MP code to 1) be compatible with ssl.sh's selfserv management (at least on Unix), and 2) mimic the way real servers handle the MP_Cache init code (calling NSS_Init after the cache set up).
      3) update ssl.sh server policy test to test policy usage on an MP server. This
      is only done for non-windows like OS's because they can't catch the kill signal
      to force their children to shutdown.
      
      I've verified that the test fails if 2 and 3 are included but 1 is not
      (and succeeds if all three are included).
      
      Differential Revision: https://phabricator.services.mozilla.com/D70948
      108aa431
  12. 06 Apr, 2020 1 commit
    • Robert Relyea's avatar
      Bug 1561637 TLS 1.3 does not work in FIPS mode r=mt · 468dbd90
      Robert Relyea authored
      Part 2 of 2
      
      Use the official PKCS #11 HKDF mechanism to implement tls 1.3.
      
      1) The new mechanism is a single derive mechanism, so we no longer need to
      pick it based on the underlying hmac (Note, we still need to know the
      underlying hmac, which is passed in as a mechanism parameter).
      
      2) Use the new keygen to generate CKK_HKDF keys rather than doing it by hand
      with the random number generator (never was really the best way of doing this).
      
      3) modify tls13hkdf.c to use the new mechanisms:
          1) Extract: use the new key handle in the mechanism parameters to pass the
          salt when the salt is a key handle.
             Extract: use the explicit NULL salt parameter if for the hash len salt of
          zeros.
          2) Expand: Expand is mostly a helper function which takes a mechanism. For
          regular expand, the mechanism is the normal _Derive, for the Raw version
          its the _Data function. That creates a data object, which is extractable
          in FIPS mode.
      
      4) update slot handling in tls13hkdf.c:
          1) we need to make sure that the key and the salt key are in the same
          slot. Provide a PK11wrap function to make that guarrentee (and use that
          function in PK11_WrapKey, which already has to do the same function).
          2) When importing a 'data' key for the zero key case, make sure we import
          into the salt key's slot. If there is no salt key, use PK11_GetBestSlot()
          rather than PK11_GetInternal slot.
      
      Differential Revision: https://phabricator.services.mozilla.com/D69899
      468dbd90
  13. 16 Mar, 2020 1 commit
  14. 07 Jan, 2020 1 commit
  15. 06 Jan, 2020 1 commit
  16. 04 Dec, 2019 1 commit
  17. 21 Nov, 2019 1 commit
  18. 01 Nov, 2019 1 commit
  19. 16 Oct, 2019 1 commit
  20. 11 Oct, 2019 1 commit
  21. 27 Sep, 2019 1 commit
  22. 23 Sep, 2019 1 commit
  23. 20 Sep, 2019 1 commit
  24. 18 Sep, 2019 1 commit
  25. 27 Aug, 2019 1 commit
    • Kevin Jacobs's avatar
      Bug 1485533 - Close gaps in taskcluster SSL testing. r=mt · 939f0611
      Kevin Jacobs authored
      This patch increases SSL testing on taskcluster, specifically, running an additional 395 tests on each SSL cycle (more for FIPS targets), and adding a new 'stress' cycle.
      
      Notable changes:
      
      1) This patch removes SSL stress tests from the default `NSS_SSL_RUN` list in all.sh and ssl.sh. If stress tests are needed, this variable must be set to include.
      
      2) The "normal_normal" case is added to `NSS_SSL_TESTS` for all targets. FIPS targets also run "normal_fips", "fips_normal", and "fips_fips".
      
      3) `--enable-libpkix` is now set for all taskcluster "build.sh" builds in order to support a number of OCSP tests that were previously not run.
      
      Differential Revision: https://phabricator.services.mozilla.com/D43283
      
      --HG--
      extra : moz-landing-system : lando
      939f0611
  26. 23 Aug, 2019 1 commit
  27. 09 Aug, 2019 1 commit
  28. 03 Jul, 2019 1 commit
  29. 10 Jul, 2019 1 commit
  30. 25 Jun, 2019 1 commit
  31. 20 May, 2019 1 commit
  32. 29 May, 2019 1 commit
  33. 22 Apr, 2019 1 commit
    • Robert Relyea's avatar
      Bug 1546229 Add IPSEC IKE support to softoken. · ecde5131
      Robert Relyea authored
      Differential Revision: https://phabricator.services.mozilla.com/D28519
      
      Patch notes:
      
      cmd/fipstest:
      
        Update fipstest to allow using old CAVS vectors in our all.sh. The various scripts have been moved to tests/fips/cavs_scripts. IKE functions were added to fipstest, and fipstest was updated to support verifying the output of ecdh and dh key agreement tests (kas).
      fipstest.c:
        NOTE: fipstest is the program NSS uses to process CAVS vectors from NIST. For historical reasons, it has known memory management issues. In general if there is a mistake, fipstest will likely crash. It has very little error checking. It has a very simplistic parser for the CAVS files. It requires the elements of the CAVS files to be in the correct order (most notably it requires the last element to always be in the last position. This is true of all the tests in fipstest, not just the new code.
        1. when verifying ec_dh and dh, accept both CAVSHashZZ and HashZZ as the input hash. This allows verify not only to verify NIST CAVS vectors, but also the output of ec_dh and dh functional tests.
        2. create ike functions modelled after the tls test functions. We test ike at the pkcs #11 level. There are three ike tests (driven by the three types of ike tests that NIST supplies):
            2.1) ikev1. This generates the ike v1 keys from the provided input. It used ike_prf to generate SKEYID and ikev1_prf to generate SKEYID_d, SKEYID_a, and SKEYID_e.
            2.2) ikev1_psk. This generates ike v1 keys from the provided input. It uses a pre-shared-secret-key. It also
      
      used ike_prf to generate SKEYID (though it uses it with bDataAsKey=false), and ikev1_prf to generate SKEYID_d, SKEYID_a, and SKEYID_e.
      
          2.3) ikev2. This generates ike v2 keys from the provided input. It uses ike_prf to generate SKEYSEED and ike_prf_plus to generate the key material. It also does a rekey using ike_prf and bRekey = true.
      3. Add parameters so the tls can be called.
      
      lib/softoken
      
        This is the main location where the new functionality is provided.
      fipstest.c
        Add the power up self test for ike. The actual test lives in sftkike.c.
      manifest.mn
        Add sftkike.c to the build.
      pkcs11.c
        Add AES XCBC MAC and IKE Mechanisms to the softoken mechanism table.
      pkcs11c.c
        sftk_MapCryptError() is now a 'global' within softoken and lives in pkcs11u.c. This was done so that sftkike.c can use it.
        sftk_InitCBCMac(). Update to handle AES XCBC., which is AES CBC MAC except 1) the underlying AES key is derived from the input key, and 2) the pad block is obscured using 2 new keys (k2, k3) also derived from the input key.
        sftk_MACFinal() handle the special pad processing for the XCBC case.
        sftk_MACUpdate() change the padding code to keep one full pad in the buffer. This won't affect normal MACs, but means that the last block in the Mac is always in the buffer so it can be processed in the XCBC case.
        NSC_DerviceKey() add the ike functions into the mechanism swtich table. The actual implementations are in sftkike.c
      pkcs11i.h
         Add the XCBC state information into the SessionContext structure.
         sftk_MapCryptError is now global, include it in the header.
         include the ike and aes_xcbc helper functions.
      pkcs11u.c
         sftk_MapCryptError() now lives in pkcs11 utilities.
      sftkike.c
         prf_* functions implement all the underlying prf specific stuff. It hides whether the prf is an hmac or aes_xcbc. If there are additional prfs, they can be implemented here without affecting the rest of the derivation code. The AES_XCBC code is aes specific. If we ever add another XCBC type operation, we would probably want to initialize some encryption functions in prf_setup and only handle the difference between hmac and xcbc in the other prf functions.
         sftk_aes_xcbc_get_keys - takes in input key and derives k1, k2, and k3. This function handles this derivation for both the prf_ functions in sftkike and the exported AES_XCBC Mac in pkcs11c.c
         sftk_xcbc_mac_pad - function to handle the correct padding method for the last block of an xcbc operation. Unlike sftk_aes_xcbc_get_keys, it is independent of the xcbc's underlying encryption method, though only AES_XCBC is defined at this time.
         sftk_ike_prf - common prf between ikev1 and ikev2 to generate SKEYID/SKEYSEED. See comments in code.
         sftk_ike1_prf - ikev1 prf to generate the session keys in ikev1 from SKEYID. See comments in code.
         sftk_ike_prf_plus - ike prf+ to generate the session keys in ikev2 from SKEYSEED. See comments in code.
         sftk_aes_xcbc_new_keys - used in pkcs11c.c to generate the 2 derived keys used in aes_xcbc. Loads k1 into the pkcs11 slot as a session key.
         prf_test - helper function to test our known test vectors for our FIPS powerup self tests.
         sftk_fips_IKE_PowerUpSelfTests - test to make sure our basic system is working correctly.
      softokn.gyp - add sftkike.c to gyp
      
      lib/util
      
      pkcs11n.h
         add defines and structures for IKE. Since they are not yet an official PKCS #11 mechanism, use CKM_NSS and CK_NSS names for them.
      pkcs11t.h
         add CKM_AES_XCBC* mechanisms. These are defined in the latest PKCS #11 spec.
      
      tests/fips
      
      The work in this directory hooks up the CAVS tests we run to do fips validation into our normal test suite. This lets us use the NIST generated samples for
      cavs_samples/* These are all vectors generated by the NIST CAVS tools (*.req) or the expected results generated by the last openssl or NSS runs and verified by the NIST CAVS tools (*.fax). These are the inputs to our fipstest. No need to detail review these. The are not explicitly included in this patch because they are too big for phabricator to handle.
      cavs_scripts/* See the read me in that directory. These scripts were originally in cmd/fipstest. I added ike.sh, and I updated the verify target of all the scripts so they they return 0 on success and 1 on failure. This allows us to use the tests in fips.sh
      fips.sh run the CAVS tests as part of the fips tests. This works to test our IKE support. Three of the cavs tests can take significant type (dsa and rsa takes several minutes, tdea is just over a minute). The code currently skips running those tests. You can run all the cavs tests by setting CAV_VECTORS=all
      
      --HG--
      branch : NSS_3_44_BRANCH
      ecde5131
  34. 21 Mar, 2019 1 commit
  35. 08 Apr, 2019 1 commit
  36. 04 Mar, 2019 1 commit
  37. 21 Mar, 2019 2 commits
  38. 10 Dec, 2018 1 commit
  39. 04 Mar, 2019 1 commit