1. 25 Jan, 2021 2 commits
    • Kevin Jacobs's avatar
      Bug 1678398 - Add Export/Import functions for HPKE context. r=mt · 10afb436
      Kevin Jacobs authored
      This patch adds and exports two new HPKE functions: `PK11_HPKE_ExportContext` and
      `PK11_HPKE_ImportContext`, which are used to export a serialized HPKE context,
      then later reimport that context and resume Open and Export operations. Only receiver
      contexts are currently supported for export (see the rationale in pk11pub.h).
      
      One other change introduced here is that `PK11_HPKE_GetEncapPubKey` now works as
      expected on the receiver side.
      
      If the `wrapKey` argument is provided to the Export/Import functions, then the
      symmetric keys are wrapped with AES Key Wrap with Padding (SP800-38F, 6.3)
      prior to serialization.
      
      Differential Revision: https://phabricator.services.mozilla.com/D99277
      
      --HG--
      extra : moz-landing-system : lando
      10afb436
    • Kevin Jacobs's avatar
      Bug 1678398 - Update HPKE to draft-07. r=mt · e2528512
      Kevin Jacobs authored
      This patch updates HPKE to draft-07. A few other minor changes are included:
      - Refactor HPKE gtests for increased parameterized testing.
      - Replace memcpy calls with PORT_Memcpy
      - Serialization tweaks to make way for context Export/Import (D99277).
      
      This should not be landed without an ECH update, as fixed ECH test vectors
      will otherwise fail to decrypt.
      
      Differential Revision: https://phabricator.services.mozilla.com/D99276
      
      --HG--
      extra : moz-landing-system : lando
      e2528512
  2. 22 Jan, 2021 1 commit
  3. 13 Jan, 2021 1 commit
  4. 22 Dec, 2020 2 commits
    • Kevin Jacobs's avatar
      Bug 1682863 - Revert nssSlot_IsTokenPresent to 3.58 after ongoing Fx hangs... · fac0bade
      Kevin Jacobs authored
      Bug 1682863 - Revert nssSlot_IsTokenPresent to 3.58 after ongoing Fx hangs with slow PKCS11 devices. r=bbeurdouche
      
      This patch reverts the `nssSlot_IsTokenPresent` changes made in bug 1663661
      and bug 1679290, restoring the version used in NSS 3.58 and earlier. It's not an
      actual `hg backout` because the comment in lib/dev/devt.h is worth keeping.
      While removing the nested locking did resolve the hang for some (most?) third-party
      modules, problems remain with some slower tokens after an even further relaxation
      of the locking, which defeats the purpose of addressing the races in the first place.
      
      The crash addressed by these patches was caused by the Intermediate Preloading
      Healer in Firefox, which has been disabled. We clearly have insufficient test
      coverage for third-party modules, and now that osclientcerts is enabled in Fx
      Nightly, any problems caused by these and similar changes is unlikely to be
      reported until Fx Beta, well after NSS RTM. I think the best option at this
      point is to simply revert NSS.
      
      Differential Revision: https://phabricator.services.mozilla.com/D100344
      
      --HG--
      extra : moz-landing-system : lando
      fac0bade
    • Robert Relyea's avatar
      Restore lost portion of the bleichenbacher timing batch that addressed · 0dfd3aa6
      Robert Relyea authored
      review comments. All the review comments pertained to actual code comments,
      so this patch only affects the comments.
      0dfd3aa6
  5. 18 Dec, 2020 2 commits
    • Robert Relyea's avatar
      Bug 1651411 New tlsfuzzer code can still detect timing issues in RSA operations. · 3a48c7de
      Robert Relyea authored
      This patch defeats Bleichenbacher by not trying to hide the size of the
      decrypted text, but to hide if the text succeeded for failed. This is done
      by generating a fake returned text that's based on the key and the cipher text,
      so the fake data is always the same for the same key and cipher text. Both the
      length and the plain text are generated with a prf.
      
      Here's the proposed spec the patch codes to:
      
          1. Use SHA-256 to hash the private exponent encoded as a big-endian integer to a string the same length as the public modulus. Keep this value secret. (this is just an optimisation so that the implementation doesn't have to serialise the key over and over again)
          2. Check the length of input according to step one of https://tools.ietf.org/html/rfc8017#section-7.2.2
          3. When provided with a ciphertext, use SHA-256 HMAC(key=hash_from_step1, text=ciphertext) to generate the key derivation key
          4. Use SHA-256 HMAC with key derivation key as the key and a two-byte big-endian iterator concatenated with byte string "length" with the big-endian representation of 2048 (0x0800) as the bit length of the generated string.
            - Iterate this PRF 8 times to generate a 256 byte string
          5. initialise the length of synthetic message to 0
          6. split the PRF output into 2 byte strings, convert into big-endian integers, zero-out high-order bits so that they have the same bit length as the octet length of the maximum acceptable message size (k-11), select the last integer that is no larger than (k-11) or remain at 0 if no integer is smaller than (k-11); this selection needs to be performed using a side-channel free operators
          7. Use SHA-256 HMAC with key derivation key as the key and a two-byte big-endian iterator concatenated with byte string "message" with the big-endian representation of k*8
            - use this PRF to generate k bytes of output (right-truncate last HMAC call if the number of generated bytes is not a multiple of SHA-256 output size)
          8. perform the RSA decryption as described in step 2 of section 7.2.2 of rfc8017
          9. Verify the EM message padding as described in step 3 of section 7.2.2 of rfc8017, but instead of outputting "decryption error", return the last l bytes of the "message" PRF, when l is the selected synthetic message length using the "length" PRF, make this decision and copy using side-channel free operation
      
      Differential Revision: https://phabricator.services.mozilla.com/D99843
      3a48c7de
    • Robert Relyea's avatar
      Bug 1682071 IKE Quick mode IPSEC give you incorrect keys if you are asking for... · a080484f
      Robert Relyea authored
      Bug 1682071 IKE Quick mode IPSEC give you incorrect keys if you are asking for keys smaller than the hash size.
      
      IKE Appendix B fixes.
      
      This patch fixes 2 problems.
      
          If you run either ike v1 App B or quick mode asking for a key with length
      
      mod macsize = 0, you will generate an extra block that's not used and
      overwrites the end of the buffer.
      
          If you use quick mode, the function incorrectly subsets the existing key
      
      rather than generating a new key. This is correct behavior for Appendix B,
      where appendix B is trying to take a generated key and create a new longer
      key (with no diversification, just transform the key into something that's
      longer), so if you ask for a key less than or equal to, then you want to just
      subset the original key. In quick mode you are taking a base key and creating
      a set of new keys based on additional data, so you want to subset the generated
      data. This patch only subsets the original key if you aren't doing quickmode.
      
      Full test vectors have now been added for all ike modes in this patch as well
      (previously we depended on the FIPS CAVS tests to test ike, which covers
      basic IKEv1, IKEv1_psk, and IKEv2 but not IKEv1 App B and IKE v1 Quick mode).
      
      Differential Revision: https://phabricator.services.mozilla.com/D99569
      a080484f
  6. 11 Dec, 2020 1 commit
  7. 04 Dec, 2020 1 commit
  8. 03 Dec, 2020 1 commit
  9. 01 Dec, 2020 4 commits
  10. 30 Nov, 2020 1 commit
  11. 01 Dec, 2020 1 commit
  12. 25 Nov, 2020 1 commit
  13. 19 Nov, 2020 1 commit
  14. 18 Nov, 2020 1 commit
  15. 17 Nov, 2020 2 commits
    • Kevin Jacobs's avatar
      Bug 1654332 - Update ESNI to draft-08 (ECH). r=mt · 4516d102
      Kevin Jacobs authored
      This patch adds support for Encrypted Client Hello (draft-ietf-tls-esni-08), replacing the existing ESNI (draft -02) support.
      
      There are five new experimental functions to enable this:
      
        - SSL_EncodeEchConfig: Generates an encoded (not BASE64) ECHConfig given a set of parameters.
        - SSL_SetClientEchConfigs: Configures the provided ECHConfig to the given socket. When configured, an ephemeral HPKE keypair will be generated for the CH encryption.
        - SSL_SetServerEchConfigs: Configures the provided ECHConfig and keypair to the socket. The keypair specified will be used for HPKE operations in order to decrypt encrypted Client Hellos as they are received.
        - SSL_GetEchRetryConfigs: If ECH is rejected by the server and compatible retry_configs are provided, this API allows the application to extract those retry_configs for use in a new connection.
        - SSL_EnableTls13GreaseEch: When enabled, non-ECH Client Hellos will have a "GREASE ECH" (i.e. fake) extension appended. GREASE ECH is disabled by default, as there are known compatibility issues that will be addressed in a subsequent draft.
      
      The following ESNI experimental functions are deprecated by this update:
      
        - SSL_EncodeESNIKeys
        - SSL_EnableESNI
        - SSL_SetESNIKeyPair
      
      
      In order to be used, NSS must be compiled with `NSS_ENABLE_DRAFT_HPKE` defined.
      
      Differential Revision: https://phabricator.services.mozilla.com/D86106
      
      --HG--
      rename : gtests/ssl_gtest/tls_esni_unittest.cc => gtests/ssl_gtest/tls_ech_unittest.cc
      rename : lib/ssl/tls13esni.c => lib/ssl/tls13ech.c
      rename : lib/ssl/tls13esni.h => lib/ssl/tls13ech.h
      extra : moz-landing-system : lando
      4516d102
    • Kevin Jacobs's avatar
      Bug 1654332 - Buffered ClientHello construction. r=mt · 85f350f0
      Kevin Jacobs authored
      This patch refactors construction of Client Hello messages. Instead of each component of the message being written separately into `ss->sec.ci.sendBuf`, we now construct the message in its own sslBuffer. Once complete, the entire message is added to the sendBuf via `ssl3_AppendHandshake`.
      
      `ssl3_SendServerHello` already uses this approach and it becomes necessary for ECH, where we use the constructed ClientHello to create an inner ClientHello.
      
      Differential Revision: https://phabricator.services.mozilla.com/D96239
      
      --HG--
      extra : moz-landing-system : lando
      85f350f0
  16. 13 Nov, 2020 1 commit
  17. 10 Nov, 2020 1 commit
  18. 09 Nov, 2020 2 commits
  19. 03 Nov, 2020 1 commit
  20. 30 Oct, 2020 1 commit
  21. 26 Oct, 2020 1 commit
  22. 23 Oct, 2020 3 commits
    • Robert Relyea's avatar
      Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism r=mt,rrelyea · ec5afba5
      Robert Relyea authored
      Summary
      
      This is useful for RSA-OAEP support.
      
      The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
      be present for PKCS#11 calls. This provides required context for OAEP.
      However, PK11_PubWrapSymKey lacks a way of providing this context and
      historically silently converted CKM_RSA_PKCS_OAEP to CKM_RSA_PKCS when
      a RSA key is provided. Introducing a new call will let us indicate
      parameters and potentially support other mechanisms in the future.
      This call mirrors the earlier calls introduced for RSA-PSS:
      PK11_SignWithMechanism and PK11_VerifyWithMechanism.
      
      The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
      be present for PKCS#11 calls. This provides required context for OAEP.
      However, PK11_PubUnwrapSymKey lacks a way of providing this context,
      and additionally lacked a way of indicating which mechanism type to use
      for the unwrap operation (instead detecting it by key type). Introducing
      a new call will let us indicate parameters and potentially support other
      mechanisms in the future.
      Signed-off-by: default avatarAlexander Scheel <ascheel@redhat.com>
      
      Differential Revision: https://phabricator.services.mozilla.com/D93424
      ec5afba5
    • 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
    • Kevin Jacobs's avatar
      Bug 1668123 - Export CERT_AddCertToListHeadWithData and CERT_AddCertToListTailWithData. r=jcj · 18e17221
      Kevin Jacobs authored
      Differential Revision: https://phabricator.services.mozilla.com/D94524
      
      --HG--
      extra : moz-landing-system : lando
      18e17221
  23. 14 Oct, 2020 2 commits
    • 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
    • J.C. Jones's avatar
      Bug 1663091 - Remove unnecessary assertions in the streaming ASN.1 decoder r=kjacobs · fd5907a0
      J.C. Jones authored
      The streaming ASN.1 decoder had assertions that, on debug builds, blocked
      embedding indefinite-length fields inside of definite-length fields/contexts,
      however that behavior does work correctly, and is valid ASN.1: it tends to
      happen when wrapping a signature around existing ASN.1-encoded data, if that
      already-encoded data had an indefinite length.
      
      Really these two assertion were just overzealous. The conditional after the
      asserts handle the case well, and memory sanitizers have not found issue here
      either.
      
      Differential Revision: https://phabricator.services.mozilla.com/D93135
      
      --HG--
      extra : moz-landing-system : lando
      fd5907a0
  24. 13 Oct, 2020 2 commits
  25. 16 Oct, 2020 1 commit
  26. 12 Oct, 2020 2 commits
  27. 24 Sep, 2020 1 commit