1. 03 Nov, 2020 3 commits
  2. 30 Oct, 2020 1 commit
  3. 26 Oct, 2020 3 commits
    • Robert Relyea's avatar
      Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1... · b0b7f9e9
      Robert Relyea authored
      Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1 signatures are disabled. r=mt
      
      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).
      
      Differential Revision: https://phabricator.services.mozilla.com/D94661
      b0b7f9e9
    • Kevin Jacobs's avatar
      Bug 1644209 - Fix broken SelectedCipherSuiteReplacer filter. r=mt · 34e2f080
      Kevin Jacobs authored
      This patch corrects the `SelectedCipherSuiteReplacer`filter to always parse the `session_id` variable (`legacy_session_id` for TLS 1.3+). The previous code attempted to skip it in 1.3+ but did not account for DTLS wire versions, resulting in intermittent failures.
      
      Differential Revision: https://phabricator.services.mozilla.com/D94632
      
      --HG--
      extra : moz-landing-system : lando
      34e2f080
    • Daiki Ueno's avatar
      Bug 1672703, always tolerate the first CCS in TLS 1.3, r=mt · be575372
      Daiki Ueno authored
      Summary:
      This flips the meaning of the flag for checking excessive CCS
      messages, so it only rejects multiple CCS messages while the first CCS
      message is always accepted.
      
      Reviewers: mt
      
      Reviewed By: mt
      
      Bug #: 1672703
      
      Differential Revision: https://phabricator.services.mozilla.com/D94603
      
      --HG--
      extra : rebase_source : dde5b59dff690e622f211c326dc8244ed652f764
      extra : amend_source : 3f0506ed64befe5b531339101b655c622151ea47
      be575372
  4. 23 Oct, 2020 5 commits
    • Robert Relyea's avatar
      Bug 1670835 Crypto Policy Support needs to be updated with disable/enable support · 4c88c8ea
      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).
      
      Differential Revision: https://phabricator.services.mozilla.com/D93697
      4c88c8ea
    • 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
    • Petr Sumbera's avatar
      97a762f0
    • 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
  5. 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
  6. 13 Oct, 2020 2 commits
  7. 16 Oct, 2020 1 commit
  8. 12 Oct, 2020 4 commits
  9. 05 Oct, 2020 1 commit
  10. 24 Sep, 2020 1 commit
  11. 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
  12. 18 Sep, 2020 2 commits
  13. 15 Sep, 2020 2 commits
  14. 14 Sep, 2020 2 commits
  15. 11 Sep, 2020 6 commits
  16. 08 Sep, 2020 1 commit
  17. 09 Sep, 2020 1 commit
  18. 08 Sep, 2020 1 commit
  19. 05 Sep, 2020 1 commit