1. 05 Feb, 2021 1 commit
  2. 04 Feb, 2021 1 commit
    • Kevin Jacobs's avatar
      Bug 1690583 - Fix CH padding extension size calculation. r=mt · 1b6a8571
      Kevin Jacobs authored
      Bug 1654332 changed the way that NSS constructs Client Hello messages. `ssl_CalculatePaddingExtLen` now receives a `clientHelloLength` value that includes the 4B handshake header. This looks okay per the inline comment (which states that only the record header is omitted from the length), but the function actually assumes that the handshake header is also omitted.
      
      This patch removes the addition of the handshake header length. Those bytes are already included in the buffered CH.
      
      Differential Revision: https://phabricator.services.mozilla.com/D103934
      
      --HG--
      extra : moz-landing-system : lando
      1b6a8571
  3. 25 Jan, 2021 3 commits
    • Kevin Jacobs's avatar
      Bug 1681585 - Update ECH to Draft-09. r=mt · 65fdf132
      Kevin Jacobs authored
      This patch updates ECH implementation to draft-09. Changes of note are:
      
      - Acceptance signal derivation is now based on the handshake secret.
      - `config_id` hint changes from 32B to 8B, trial decryption added on the server.
      - Duplicate code in HRR cookie handling has been consolidated into `tls13_HandleHrrCookie`.
      - `ech_is_inner` extension is added, which causes a server to indicate ECH acceptance.
      - Per the above, support signaling ECH acceptance when acting as a backend server in split-mode
        (i.e. when there is no other local Encrypted Client Hello state).
      
      Differential Revision: https://phabricator.services.mozilla.com/D101049
      
      --HG--
      extra : moz-landing-system : lando
      65fdf132
    • 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
  4. 13 Jan, 2021 2 commits
  5. 22 Dec, 2020 1 commit
  6. 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
  7. 11 Dec, 2020 3 commits
  8. 04 Dec, 2020 1 commit
  9. 17 Nov, 2020 1 commit
    • 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
  10. 03 Nov, 2020 3 commits
  11. 26 Oct, 2020 2 commits
  12. 23 Oct, 2020 2 commits
  13. 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
  14. 12 Oct, 2020 2 commits
  15. 24 Sep, 2020 1 commit
  16. 23 Sep, 2020 1 commit
    • Dana Keeler's avatar
      Bug 1665715 - (2/2) pass encoded signed certificate timestamp extension (if... · 33c0a6a3
      Dana Keeler authored
      Bug 1665715 - (2/2) pass encoded signed certificate timestamp extension (if present) in CheckRevocation r=jcj
      
      This will allow Firefox to make decisions based on the earliest known time that
      a certificate exists (with respect to certificate transparency) that a CA is
      unlikely to back-date. In particular, this is essential for CRLite. Note that
      if the SCT signature isn't validated, a CA could still make a certificate
      appear to have existed for longer than it really has. However, this change is
      not an attempt to catch malicious CAs. The aim is to avoid false positives in
      CRLite resulting from CAs backdating the notBefore field on certificates they
      issue.
      
      Depends on D90595
      
      Differential Revision: https://phabricator.services.mozilla.com/D90596
      
      --HG--
      extra : moz-landing-system : lando
      33c0a6a3
  17. 18 Sep, 2020 1 commit
  18. 08 Sep, 2020 1 commit
  19. 24 Aug, 2020 1 commit
  20. 07 Aug, 2020 1 commit
  21. 05 Aug, 2020 1 commit
  22. 27 Jul, 2020 2 commits
    • Robert Relyea's avatar
    • Robert Relyea's avatar
      Bug 1648822 Add stricter validation of DH keys when in FIPS mode. · c817f229
      Robert Relyea authored
      Update:
      FIPS now also requires us to do y^q mod p testing on key generation (always).
      We now do that in FIPS mode only, but in all modes we do full DH verification
      for DH and ECDH. Because of this, the path has now separated out the prime
      checks, which are now only done for the DH operation if we aren't using a known
      prime and the subprime value has been provided. I've also learned we can accept
      keys that we do full validation on in FIPS mode, so I've added that to
      this patch, though we still can't generate those kinds of keys without
      adding the subprime at keygen time.
      
      The new FIPS standard is dh operations must use approved primes. Approved
      primes are those selected in the tls and ike RFCs. Currently tls and ike
      have modes with checks whether the primes are approved, but the check may
      not always happen. The safest thing to do in FIPS mode is only allow those
      primes. In addition, FIPS requires 1< y < p-1 (or technically 2<=y<=p-2, since
      y is an integer those two tests are identical).
      
      While making changes I realized we would want a mode where we can do more strict
      checks on the prime while not requiring that the prime be an approved prime. We
      already allow for strict checking if q is supplied with the private key, but there
      were a couple of issues with that check:
      
          1. there was no way of actually setting q in the current NSS pk11wrap interfaces.
          2. If the prime was a safe prime, but g was an actual generator, then we would fail the y^q mod p = 1 tests for 50% of the keys, even though those keys are safe.
          3. We weren't checking primality of p and q.
      
      So the old code:
      
        if (q) {
          check y^q mod p = 1
          if not fail
        }
      
        check 1 <y < p-1 (done in DH_Derive).
      
      New code:
      
       if (! p is approved prime) {
         if (FIPS) fail;
         if (q) {
            y_test = y
            if (p,q-> p is a safe prime) {
               y_test = 1
            }
            check prime is prime Fail if not
            check subprime is subprime fail if not
            y_test^q mod p = 1
         }
       }
       check 1 < y < p-1 (done in DH_Derive)
      
      This means:
      
      Existing code non-fips without setting the subprime continues to run as before.
      Non-fips code which sets the subprime now runs slower, but p and q are checked
        if p or q where not prime, the derive fails (which it should).
      In FIPS mode only approved primes will succeed now.
      Non-fips code can now set the subprime to q=(p-1)/2 if it doesn't have an
      explicit q value (like in tls). If the derive succeeds, we know that p is a
      safe prime. If p is approved, the checks are skipped because we already know
      that p is a safe prime. Code can optionally do a test derive on a new p and
      remember it's safe so that we know longer need to  check ever call (though if
      q is not (p-1)/2, you will need to  continue to do the checks each call
      because y could still be a small subgroup).
      
      This patch:
      
      gtests/softoken_gtest
      
        1. Added New dh tests to softoken_gtests. The tests were added to softoken_gtests
      because we need to test both non-FIPS and FIPS mode. Test vectors include a
      category, so the same test vectors can be used in FIPS and non-FIPS even though
      each class may have different results. Most of the test vectors where created
      either by dhparams command in openssl, dsaparams in openssl, and the nss makepqg
      command. Each vector includes a label, prime, base, optional subprime, optional
      public key, test type, and key class (basically size).
        2. If public key is not supplied, we use a generated public key.
        3. If subPrime is supplied to wet it on the private key after generation.
      
      lib/freebl/dh.c
      
          add primality tests to KEA_VerifyKey().
      
      lib/softokn/
      
        1. Allow CKA_SUBPRIME to be set after key generation or import. This affects
      how we test for it's existance, since it is now always there on the key, we
      check it's length to make sure it's non-zero.
        2. We implement the psuedocode above as real code.
        3. We create two new functions: sftl_VerifyDH_Prime which return SECSuccess if Prime is an approved prime. sftk_IsSafePrime which returns SECSuess of both prime and subprime look reasonable, and sets a Bool to PR_TRUE is subprime -> prime is safe (subprime = (prime-1)/2. These functions are implemented in sftkdhverify.c
        4.Cleanup incorrect nominclature on primes (safe primes are not strong primes).
      c817f229
  23. 18 Jul, 2020 2 commits
  24. 10 Jul, 2020 1 commit
    • Daiki Ueno's avatar
      Bug 1646324, advertise rsa_pkcs1_* schemes in CH and CR for certs, r=mt · 69f4843c
      Daiki Ueno authored
      Summary:
      In TLS 1.3, unless "signature_algorithms_cert" is advertised, the
      "signature_algorithms" extension is used as an indication of supported
      algorithms for signatures on certificates.  While rsa_pkcs1_*
      signatures schemes cannot be used for signing handshake messages, they
      should be advertised if the peer wants to to support certificates
      signed with RSA PKCS#1.
      
      This adds a flag to ssl3_EncodeSigAlgs() and ssl3_FilterSigAlgs() to
      preserve rsa_pkcs1_* schemes in the output.
      
      Reviewers: mt
      
      Reviewed By: mt
      
      Bug #: 1646324
      
      Differential Revision: https://phabricator.services.mozilla.com/D80881
      
      --HG--
      extra : rebase_source : d58be09155b7b197f2500b8831f3b0f1ae8a30f0
      extra : amend_source : 0a4cfe26f33dcf3cee44e1001f844d8012350fd0
      69f4843c
  25. 09 Jul, 2020 1 commit
  26. 08 Jul, 2020 1 commit
    • Kevin Jacobs's avatar
      Bug 1647752 - Update DTLS 1.3 implementation to draft-38. r=mt · a412e70e
      Kevin Jacobs authored
      This patch updates DTLS 1.3 to draft-38. Specifically:
      
      
        # `ssl_ct_ack` value changes from 25 to 26.
        # AEAD limits in `tls13_UnprotectRecord` enforce a maximum of 2^36-1 (as we only support GCM/ChaCha20 AEADs) decryption failures before the connection is closed.
        # Post-handshake authentication will no longer be negotiated in DTLS 1.3. This allows us to side-step the more convoluted state machine requirements.
      
      Differential Revision: https://phabricator.services.mozilla.com/D82421
      
      --HG--
      extra : moz-landing-system : lando
      a412e70e
  27. 07 Jul, 2020 1 commit