summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Added tag NSS_3_61_RTM for changeset b09bdf93e079NSS_3_61_BRANCHKevin Jacobs2021-01-220-0/+0
|
* Set version numbers to 3.61 finalNSS_3_61_RTMKevin Jacobs2021-01-223-6/+6
|
* Added tag NSS_3_61_BETA1 for changeset 68ae9b456b1bKevin Jacobs2021-01-190-0/+0
|
* Bug 1686557 - Support aarch64-make target in nss-try. r=bbeurdoucheNSS_3_61_BETA1Kevin Jacobs2021-01-131-2/+4
| | | | Differential Revision: https://phabricator.services.mozilla.com/D101648
* Bug 1684300 - Define USE_STATIC_LIBS=1 for softoken_gtest make builds. ↵Kevin Jacobs2021-01-131-1/+2
| | | | | | r=bbeurdouche Differential Revision: https://phabricator.services.mozilla.com/D101668
* Bug 1684300 - Disable legacy storage when compiled with NSS_DISABLE_DBM. r=mtKevin Jacobs2021-01-135-2/+70
| | | | Differential Revision: https://phabricator.services.mozilla.com/D101218
* Bug 1682863 - Revert nssSlot_IsTokenPresent to 3.58 after ongoing Fx hangs ↵Kevin Jacobs2020-12-221-30/+6
| | | | | | | | | | | | | | | | | | | | 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
* Restore lost portion of the bleichenbacher timing batch that addressedRobert Relyea2020-12-224-15/+14
| | | | | review comments. All the review comments pertained to actual code comments, so this patch only affects the comments.
* Bug 1651411 New tlsfuzzer code can still detect timing issues in RSA operations.Robert Relyea2020-12-1812-247/+3270
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Bug 1682071 IKE Quick mode IPSEC give you incorrect keys if you are asking ↵Robert Relyea2020-12-1710-2/+887
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Bug 1677207 - Use GTEST_SKIP in ssl_gtests. r=bbeurdoucheKevin Jacobs2020-12-118-21/+19
| | | | Differential Revision: https://phabricator.services.mozilla.com/D98821
* Bug 1677207 - Replace references to TestCase, which is deprecated, with ↵Kevin Jacobs2020-12-1162-320/+325
| | | | | | | | | TestSuite r=bbeurdouche grep -rl --exclude-dir=google_test INSTANTIATE_TEST_CASE_P gtests | xargs sed -i '' s/INSTANTIATE_TEST_CASE_P/INSTANTIATE_TEST_SUITE_P/g grep -rl --exclude-dir=google_test SetUpTestCase gtests | xargs sed -i '' s/SetUpTestCase/SetUpTestSuite/g Differential Revision: https://phabricator.services.mozilla.com/D98818
* Bug 1677207 - Update Google Test to release-1.10.0 r=bbeurdoucheKevin Jacobs2020-12-11164-29091/+14543
| | | | | | ./gtests/google_test/update.sh release-1.10.0 && hg remove -A && hg add gtests/google_test/* Differential Revision: https://phabricator.services.mozilla.com/D98814
* Set version numbers to 3.61 BetaKevin Jacobs2020-12-115-26/+7
|
* Added tag NSS_3_60_BETA1 for changeset f84fb229842aKevin Jacobs2020-12-080-0/+0
|
* Bug 1680400 - Fix memory leak in PK11_UnwrapPrivKey. r=bbeurdoucheNSS_3_60_BETA1Kevin Jacobs2020-12-042-6/+14
| | | | Differential Revision: https://phabricator.services.mozilla.com/D98772
* Bug 1570539 - Removed -X alt-server-hello option from tstclnt r=kjacobsyogesh2020-12-031-1/+0
| | | | Differential Revision: https://phabricator.services.mozilla.com/D98634
* Bug 1675523 - CKR_PUBLIC_KEY_INVALID has an incorrect value r=bbeurdoucheJ.C. Jones2020-12-031-1/+1
| | | | | | | | | | PKCS#11 v2.40: https://www.cryptsoft.com/pkcs11doc/STANDARD/include/v240/pkcs11t.h line 1150 jdk8u: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/eb7f437285a1/src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h#l1155 Differential Revision: https://phabricator.services.mozilla.com/D97337
* Bug 1678189 - December 2020 batch of root changes, ↵Kevin Jacobs2020-12-011-2/+2
| | | | | | NSS_BUILTINS_LIBRARY_VERSION 2.46. r=bbeurdouche Differential Revision: https://phabricator.services.mozilla.com/D98268
* Bug 1678166 - Add NAVER Global Root Certification Authority root cert to ↵Kevin Jacobs2020-12-011-0/+174
| | | | | | NSS. r=bbeurdouche,KathleenWilson Differential Revision: https://phabricator.services.mozilla.com/D98196
* Bug 1670769 - Remove 10 GeoTrust, thawte, and VeriSign root certs from NSS. ↵Benjamin Beurdouche2020-12-011-1570/+0
| | | | | | r=kjacobs,KathleenWilson Differential Revision: https://phabricator.services.mozilla.com/D97956
* Bug 1674819 - Fix undefined shift when fuzzing r=bbeurdoucheKevin Jacobs2020-12-011-0/+7
| | | | | | In fuzzer mode, session tickets are serialized without any encryption or integrity protection. This leads to a post-deserialize UBSAN error when shifting by a fuzzed (large) authType value. A real NSS server will not produce these values. Differential Revision: https://phabricator.services.mozilla.com/D97803
* Bug 1678384 - Add a build flag to allow building nssckbi-testlib in m-c ↵Benjamin Beurdouche2020-11-305-1/+40
| | | | | | r=kjacobs Differential Revision: https://phabricator.services.mozilla.com/D98154
* Bug 1679290 - Don't hold slot lock when taking session lock r=bbeurdoucheKevin Jacobs2020-12-011-0/+14
| | | | | | | | [[ https://hg.mozilla.org/projects/nss/rev/0ed11a5835ac1556ff978362cd61069d48f4c5db | 0ed11a5835ac1556ff978362cd61069d48f4c5db ]] fixed a number of race conditions related to NSSSlot member accesses. Unfortunately the locking order that was imposed by that patch has been found to cause problems for at least one PKCS11 module, libnsspem. This patch drops nested locking in favor of unlocking/re-locking. While this isn't perfect, the original problem in bug 1663661 was that `slot->token` could become NULL, which we can easily check after reacquiring. Differential Revision: https://phabricator.services.mozilla.com/D98247
* Bug 1678990 - Use __ARM_FEATURE_CRYPTO for feature detection. r=bbeurdoucheMakoto Kato2020-11-251-0/+9
| | | | | | | | | | Actually, we have CPU feature detection for Linux and FreeBSD on aarch64 platform. But others don't. macOS doesn't has any CPU feature detection for ARM Crypto Extension, but toolchain default is turned on. So we should respect __ARM_FEATURE_CRYPTO. Differential Revision: https://phabricator.services.mozilla.com/D97909
* Bug 1642174 - Resolve sha512-p8.o: ABI version 2 is not compatible with ABI ↵Lauri Kasanen2020-11-191-1/+4
| | | | | | | | | | | version 1 output. r=jcj Don't try to build the SHA-2 accelerated asm on old-ABI ppc. Currently make only, I don't have enough gyp-fu to do that side. However, the reporters of 1642174 and 1635625 both used make, not gyp. Signed-off-by: Lauri Kasanen <cand@gmx.com>
* Bug 1654332 - Fixup a10493dcfcc9: copy ECHConfig.config_id with socket r=jcjKevin Jacobs2020-11-183-2/+3
| | | | | | A late review change for ECH was for the server to compute each ECHConfig `config_id` when set to the socket, rather than on each connection. This works, but now we also need to copy that config_id when copying a socket, else the server won't find a matching ECHConfig to use for decryption. Differential Revision: https://phabricator.services.mozilla.com/D97475
* Bug 1654332 - Update ESNI to draft-08 (ECH). r=mtKevin Jacobs2020-11-1747-2062/+5192
| | | | | | | | | | | | | | | | | | | | | | | 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
* Bug 1654332 - Buffered ClientHello construction. r=mtKevin Jacobs2020-11-175-251/+367
| | | | | | | | 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
* Set version numbers to 3.60 BetaJ.C. Jones2020-11-136-21/+7
|
* Added tag NSS_3_59_BETA1 for changeset c3cb09a7d087J.C. Jones2020-11-100-0/+0
|
* Bug 1607449 - Lock cert->nssCertificate to prevent data race. r=jcj,keelerNSS_3_59_BETA1Kevin Jacobs2020-11-104-21/+63
| | | | Differential Revision: https://phabricator.services.mozilla.com/D64233
* Backed out changeset aa6f29a76cfc for Certificates test failuresJ.C. Jones2020-11-094-41/+21
|
* Backed out changeset d8df719915f7 for Certificates test failuresJ.C. Jones2020-11-090-0/+0
|
* Added tag NSS_3_59_BETA1 for changeset aa6f29a76cfcJ.C. Jones2020-11-090-0/+0
|
* Bug 1607449 - Lock cert->nssCertificate to prevent data race. r=keelerKevin Jacobs2020-11-094-21/+41
| | | | Differential Revision: https://phabricator.services.mozilla.com/D64233
* Bug 1672823 - Add Wycheproof HMAC test cases. r=jcjKevin Jacobs2020-11-037-0/+3402
| | | | Differential Revision: https://phabricator.services.mozilla.com/D94497
* Bug 1672823 - Add Wycheproof HKDF test cases. r=bbeurdoucheKevin Jacobs2020-11-039-356/+6205
| | | | Differential Revision: https://phabricator.services.mozilla.com/D94496
* Bug 1672823 - Add Wycheproof DSA test cases. r=jcjKevin Jacobs2020-11-037-3/+21189
| | | | Differential Revision: https://phabricator.services.mozilla.com/D94495
* Bug 1663661 - Guard against NULL token in nssSlot_IsTokenPresent. r=jcjKevin Jacobs2020-11-032-6/+19
| | | | | | This patch addresses locking inconsistency in `nssSlot_IsTokenPresent` by retaining the slot lock for the duration of accesses to `slot->token`. This is already done correctly elsewhere. As a side effect, this introduces an ordering requirement: we take `slot->lock` followed by `session->lock`. Differential Revision: https://phabricator.services.mozilla.com/D95636
* Bug 1670835 - Fixup for 6f79a7695812, add missing return value check. r=rrelyeaKevin Jacobs2020-10-301-1/+4
| | | | Differential Revision: https://phabricator.services.mozilla.com/D95221
* Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1 ↵Robert Relyea2020-10-266-5/+138
|\ | | | | | | | | | | | | | | | | | | 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
| * Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1 ↵Robert Relyea2020-10-236-5/+136
| | | | | | | | | | | | | | | | 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).
* | Bug 1644209 - Fix broken SelectedCipherSuiteReplacer filter. r=mtKevin Jacobs2020-10-261-6/+6
| | | | | | | | | | | | 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
* | Bug 1672703, always tolerate the first CCS in TLS 1.3, r=mtDaiki Ueno2020-10-263-26/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Bug 1670835 Crypto Policy Support needs to be updated with disable/enable ↵Robert Relyea2020-10-2321-138/+614
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | support 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
| * | Bug 1670835 Crypto Policy Support needs to be updated with disable/enable ↵Robert Relyea2020-10-1421-138/+614
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | support 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).
* | | Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism r=mt,rrelyeaRobert Relyea2020-10-235-12/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alexander Scheel <ascheel@redhat.com> Differential Revision: https://phabricator.services.mozilla.com/D93424
* | | Bug 1667989 - coreconf/config.gypi should allow correct linking on Solaris ↵Petr Sumbera2020-10-231-5/+7
| | | | | | | | | | | | | | | | | | r=kjacobs,bbeurdouche Differential Revision: https://phabricator.services.mozilla.com/D26278
* | | Bug 1668123 - Export CERT_AddCertToListHeadWithData and ↵Kevin Jacobs2020-10-233-0/+47
| | | | | | | | | | | | | | | | | | CERT_AddCertToListTailWithData. r=jcj Differential Revision: https://phabricator.services.mozilla.com/D94524
View Lorry Controller Status