f1e48fbead3d9e69500d7aedc1ef6e4bf334f41e: Bug 1678990 - Use __ARM_FEATURE_CRYPTO for feature detection. r=bbeurdouche default tip
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Wed, 25 Nov 2020 10:53:42 +0000 - rev 15805
Push 3880 by kjacobs@mozilla.com at Wed, 25 Nov 2020 19:40:56 +0000
Bug 1678990 - Use __ARM_FEATURE_CRYPTO for feature detection. r=bbeurdouche 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
d806f7992b10aa9a4dd62d8bf1f1248ae1dab008: Bug 1642174 - Resolve sha512-p8.o: ABI version 2 is not compatible with ABI version 1 output. r=jcj
Lauri Kasanen <cand@gmx.com> - Thu, 19 Nov 2020 12:11:45 -0800 - rev 15804
Push 3879 by kjacobs@mozilla.com at Thu, 19 Nov 2020 20:19:03 +0000
Bug 1642174 - Resolve sha512-p8.o: ABI version 2 is not compatible with ABI 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>
3eacb92e9adf0e250eca309690c3f9a8a257da3b: Bug 1654332 - Fixup a10493dcfcc9: copy ECHConfig.config_id with socket r=jcj
Kevin Jacobs <kjacobs@mozilla.com> - Wed, 18 Nov 2020 20:08:53 +0000 - rev 15803
Push 3878 by kjacobs@mozilla.com at Wed, 18 Nov 2020 20:15:19 +0000
Bug 1654332 - Fixup a10493dcfcc9: copy ECHConfig.config_id with socket r=jcj 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
a10493dcfcc92cb9bad985b151325238b6e38b09: Bug 1654332 - Update ESNI to draft-08 (ECH). r=mt
Kevin Jacobs <kjacobs@mozilla.com> - Tue, 17 Nov 2020 23:43:25 +0000 - rev 15802
Push 3877 by kjacobs@mozilla.com at Tue, 17 Nov 2020 23:56:56 +0000
Bug 1654332 - Update ESNI to draft-08 (ECH). r=mt 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
d40121ba59ba02c45fd2736f6e096b3b464916a9: Bug 1654332 - Buffered ClientHello construction. r=mt
Kevin Jacobs <kjacobs@mozilla.com> - Tue, 17 Nov 2020 22:13:40 +0000 - rev 15801
Push 3876 by kjacobs@mozilla.com at Tue, 17 Nov 2020 22:17:33 +0000
Bug 1654332 - Buffered ClientHello construction. r=mt 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
5e7b37609f22370be222686a38c0e12c62c27704: Set version numbers to 3.60 Beta
J.C. Jones <jjones@mozilla.com> - Fri, 13 Nov 2020 12:07:21 -0700 - rev 15800
Push 3875 by jjones@mozilla.com at Fri, 13 Nov 2020 19:32:01 +0000
Set version numbers to 3.60 Beta
69d4b94977f182662b3e9bda1294052c3076e224: Added tag NSS_3_59_RTM for changeset c5d760cbe8d0 NSS_3_59_BRANCH
J.C. Jones <jjones@mozilla.com> - Fri, 13 Nov 2020 12:06:43 -0700 - rev 15799
Push 3874 by jjones@mozilla.com at Fri, 13 Nov 2020 19:31:21 +0000
Added tag NSS_3_59_RTM for changeset c5d760cbe8d0
c5d760cbe8d0c2221a2785db977bd1f1475510ca: Set version numbers to 3.59 final NSS_3_59_BRANCH NSS_3_59_RTM
J.C. Jones <jjones@mozilla.com> - Fri, 13 Nov 2020 12:06:28 -0700 - rev 15798
Push 3874 by jjones@mozilla.com at Fri, 13 Nov 2020 19:31:21 +0000
Set version numbers to 3.59 final
06e965656f085854844e13e72044d29e2f6eb2f1: Added tag NSS_3_59_BETA1 for changeset c3cb09a7d087
J.C. Jones <jjones@mozilla.com> - Tue, 10 Nov 2020 11:57:03 -0700 - rev 15797
Push 3873 by jjones@mozilla.com at Tue, 10 Nov 2020 18:57:33 +0000
Added tag NSS_3_59_BETA1 for changeset c3cb09a7d087
c3cb09a7d08766701c7614879701b22af47543a8: Bug 1607449 - Lock cert->nssCertificate to prevent data race. r=jcj,keeler NSS_3_59_BETA1
Kevin Jacobs <kjacobs@mozilla.com> - Tue, 10 Nov 2020 17:40:07 +0000 - rev 15796
Push 3872 by jjones@mozilla.com at Tue, 10 Nov 2020 17:43:07 +0000
Bug 1607449 - Lock cert->nssCertificate to prevent data race. r=jcj,keeler Differential Revision: https://phabricator.services.mozilla.com/D64233
6ad80d21f30cf0787fddd08d1900ce6199bdeeed: Backed out changeset aa6f29a76cfc for Certificates test failures
J.C. Jones <jjones@mozilla.com> - Mon, 09 Nov 2020 11:26:00 -0700 - rev 15795
Push 3871 by jjones@mozilla.com at Mon, 09 Nov 2020 18:26:51 +0000
Backed out changeset aa6f29a76cfc for Certificates test failures
2bc4260e4ecbd4b8471f0fcd6429fc7ab325527c: Backed out changeset d8df719915f7 for Certificates test failures
J.C. Jones <jjones@mozilla.com> - Mon, 09 Nov 2020 11:25:30 -0700 - rev 15794
Push 3871 by jjones@mozilla.com at Mon, 09 Nov 2020 18:26:51 +0000
Backed out changeset d8df719915f7 for Certificates test failures
d8df719915f7485f82cf0815a4d7e48e676a4604: Added tag NSS_3_59_BETA1 for changeset aa6f29a76cfc
J.C. Jones <jjones@mozilla.com> - Mon, 09 Nov 2020 10:57:04 -0700 - rev 15793
Push 3870 by jjones@mozilla.com at Mon, 09 Nov 2020 18:08:48 +0000
Added tag NSS_3_59_BETA1 for changeset aa6f29a76cfc
aa6f29a76cfca9026b595f3cd52ffc76f18e8508: Bug 1607449 - Lock cert->nssCertificate to prevent data race. r=keeler
Kevin Jacobs <kjacobs@mozilla.com> - Mon, 09 Nov 2020 17:53:21 +0000 - rev 15792
Push 3869 by jjones@mozilla.com at Mon, 09 Nov 2020 17:55:41 +0000
Bug 1607449 - Lock cert->nssCertificate to prevent data race. r=keeler Differential Revision: https://phabricator.services.mozilla.com/D64233
97751cd6d55349944837018475fc3b9e922575fa: Bug 1672823 - Add Wycheproof HMAC test cases. r=jcj
Kevin Jacobs <kjacobs@mozilla.com> - Tue, 03 Nov 2020 06:13:37 +0000 - rev 15791
Push 3868 by kjacobs@mozilla.com at Tue, 03 Nov 2020 20:56:15 +0000
Bug 1672823 - Add Wycheproof HMAC test cases. r=jcj Differential Revision: https://phabricator.services.mozilla.com/D94497
5a02ca2617cf7cfa7798cb24d10014f6c761397f: Bug 1672823 - Add Wycheproof HKDF test cases. r=bbeurdouche
Kevin Jacobs <kjacobs@mozilla.com> - Tue, 03 Nov 2020 03:59:34 +0000 - rev 15790
Push 3868 by kjacobs@mozilla.com at Tue, 03 Nov 2020 20:56:15 +0000
Bug 1672823 - Add Wycheproof HKDF test cases. r=bbeurdouche Differential Revision: https://phabricator.services.mozilla.com/D94496
3ce42ead87f9b629de37d91068f65e7006538ebc: Bug 1672823 - Add Wycheproof DSA test cases. r=jcj
Kevin Jacobs <kjacobs@mozilla.com> - Tue, 03 Nov 2020 18:25:26 +0000 - rev 15789
Push 3868 by kjacobs@mozilla.com at Tue, 03 Nov 2020 20:56:15 +0000
Bug 1672823 - Add Wycheproof DSA test cases. r=jcj Differential Revision: https://phabricator.services.mozilla.com/D94495
0ed11a5835ac1556ff978362cd61069d48f4c5db: Bug 1663661 - Guard against NULL token in nssSlot_IsTokenPresent. r=jcj
Kevin Jacobs <kjacobs@mozilla.com> - Tue, 03 Nov 2020 19:02:15 +0000 - rev 15788
Push 3867 by kjacobs@mozilla.com at Tue, 03 Nov 2020 19:07:41 +0000
Bug 1663661 - Guard against NULL token in nssSlot_IsTokenPresent. r=jcj 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
424974716ef0af19fc1c1c865f4415e64d55dd67: Bug 1670835 - Fixup for 6f79a7695812, add missing return value check. r=rrelyea
Kevin Jacobs <kjacobs@mozilla.com> - Fri, 30 Oct 2020 17:09:49 +0000 - rev 15787
Push 3866 by kjacobs@mozilla.com at Mon, 02 Nov 2020 16:14:24 +0000
Bug 1670835 - Fixup for 6f79a7695812, add missing return value check. r=rrelyea Differential Revision: https://phabricator.services.mozilla.com/D95221
035110dfa0b9a7f755860020fbbb7296c543d63b: Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1 signatures are disabled. r=mt
Robert Relyea <rrelyea@redhat.com> - Mon, 26 Oct 2020 15:50:51 -0700 - rev 15786
Push 3865 by rrelyea@redhat.com at Mon, 26 Oct 2020 22:50:59 +0000
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
97f69f7a89a1a31b5acb05a551560e62b65495d4: Bug 1672291 libpkix OCSP failures on SHA1 self-signed root certs when SHA1 signatures are disabled.
Robert Relyea <rrelyea@redhat.com> - Fri, 23 Oct 2020 14:35:52 -0700 - rev 15785
Push 3865 by rrelyea@redhat.com at Mon, 26 Oct 2020 22:50:59 +0000
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).
a79d14b06b4a3ca19c169a4b0c1f28d5e2f25b35: Bug 1644209 - Fix broken SelectedCipherSuiteReplacer filter. r=mt
Kevin Jacobs <kjacobs@mozilla.com> - Mon, 26 Oct 2020 14:47:41 +0000 - rev 15784
Push 3864 by kjacobs@mozilla.com at Mon, 26 Oct 2020 15:04:35 +0000
Bug 1644209 - Fix broken SelectedCipherSuiteReplacer filter. r=mt 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
b03a4fc5b902498414b02640dcb2717dfef9682f: Bug 1672703, always tolerate the first CCS in TLS 1.3, r=mt
Daiki Ueno <dueno@redhat.com> - Mon, 26 Oct 2020 06:46:11 +0100 - rev 15783
Push 3863 by dueno@redhat.com at Mon, 26 Oct 2020 05:47:47 +0000
Bug 1672703, always tolerate the first CCS in TLS 1.3, r=mt 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
6f79a76958129dc09c353c288f115fd9a51ab7d4: Bug 1670835 Crypto Policy Support needs to be updated with disable/enable support
Robert Relyea <rrelyea@redhat.com> - Fri, 23 Oct 2020 16:14:36 -0700 - rev 15782
Push 3862 by rrelyea@redhat.com at Sat, 24 Oct 2020 00:05:56 +0000
Bug 1670835 Crypto Policy Support needs to be updated with disable/enable 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
2c791b3afb329faffcaaaf3c752fa54c6f297a2f: Bug 1670835 Crypto Policy Support needs to be updated with disable/enable support
Robert Relyea <rrelyea@redhat.com> - Wed, 14 Oct 2020 11:37:52 -0700 - rev 15781
Push 3862 by rrelyea@redhat.com at Sat, 24 Oct 2020 00:05:56 +0000
Bug 1670835 Crypto Policy Support needs to be updated with disable/enable 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).
33f920fcd1753d2b8f4a5e4f31e317c102d8cbfe: Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism r=mt,rrelyea
Robert Relyea <rrelyea@redhat.com> - Fri, 23 Oct 2020 15:34:01 -0700 - rev 15780
Push 3861 by rrelyea@redhat.com at Fri, 23 Oct 2020 22:34:27 +0000
Bug 1666891 - Add PK11_Pub{Wrap,Unwrap}SymKeyWithMechanism r=mt,rrelyea 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
e3bd9c2f925932b301440fb07ea1228f2d4e39ac: Bug 1667989 - coreconf/config.gypi should allow correct linking on Solaris r=kjacobs,bbeurdouche
Petr Sumbera <petr.sumbera@oracle.com> - Fri, 23 Oct 2020 20:34:27 +0000 - rev 15779
Push 3860 by kjacobs@mozilla.com at Fri, 23 Oct 2020 20:36:50 +0000
Bug 1667989 - coreconf/config.gypi should allow correct linking on Solaris r=kjacobs,bbeurdouche Differential Revision: https://phabricator.services.mozilla.com/D26278
0f15b05daeed54e3a52ce476d3011d14b63725df: Bug 1668123 - Export CERT_AddCertToListHeadWithData and CERT_AddCertToListTailWithData. r=jcj
Kevin Jacobs <kjacobs@mozilla.com> - Fri, 23 Oct 2020 15:49:49 +0000 - rev 15778
Push 3859 by kjacobs@mozilla.com at Fri, 23 Oct 2020 16:23:13 +0000
Bug 1668123 - Export CERT_AddCertToListHeadWithData and CERT_AddCertToListTailWithData. r=jcj Differential Revision: https://phabricator.services.mozilla.com/D94524
7076e78ddafe8beed50903106c656facd7e32f3c: Bug 1634584 - Set CKA_NSS_SERVER_DISTRUST_AFTER for Trustis FPS Root CA. r=kjacobs
Benjamin Beurdouche <bbeurdouche@mozilla.com> - Thu, 30 Jul 2020 19:08:56 +0000 - rev 15777
Push 3858 by jjones@mozilla.com at Wed, 21 Oct 2020 15:55:40 +0000
Bug 1634584 - Set CKA_NSS_SERVER_DISTRUST_AFTER for Trustis FPS Root CA. r=kjacobs Differential Revision: https://phabricator.services.mozilla.com/D85330
d0153cc0c464b257cb6ef87a68e216eb10d501b4: Bug 1663091 - Remove unnecessary assertions in the streaming ASN.1 decoder r=kjacobs
J.C. Jones <jjones@mozilla.com> - Wed, 14 Oct 2020 02:23:44 +0000 - rev 15776
Push 3857 by jjones@mozilla.com at Tue, 20 Oct 2020 15:59:26 +0000
Bug 1663091 - Remove unnecessary assertions in the streaming ASN.1 decoder r=kjacobs 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
(0) -10000 -3000 -1000 -300 -100 -50 -30 tip