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
      extra : moz-landing-system : lando
    • 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
      extra : moz-landing-system : lando
  2. 23 Jan, 2021 1 commit
  3. 22 Jan, 2021 1 commit
  4. 19 Jan, 2021 1 commit
  5. 13 Jan, 2021 3 commits
  6. 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
      extra : moz-landing-system : lando
    • 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.
  7. 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
    • 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
  8. 11 Dec, 2020 4 commits
  9. 08 Dec, 2020 1 commit
  10. 04 Dec, 2020 1 commit
  11. 03 Dec, 2020 2 commits
  12. 01 Dec, 2020 4 commits
  13. 30 Nov, 2020 1 commit
  14. 01 Dec, 2020 1 commit
  15. 25 Nov, 2020 1 commit
  16. 19 Nov, 2020 1 commit
  17. 18 Nov, 2020 1 commit
  18. 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
      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
    • 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
      extra : moz-landing-system : lando
  19. 13 Nov, 2020 1 commit
  20. 10 Nov, 2020 2 commits
  21. 09 Nov, 2020 4 commits
  22. 03 Nov, 2020 2 commits