c06f22733446c6fb55362b9707fa714c15caf04e: Bug 1625791 - Call STAN_GetCERTCertificate to load CERTCertificate trust before caching. r=jcj,keeler default tip
Kevin Jacobs <kjacobs@mozilla.com> - Fri, 07 Aug 2020 22:15:00 +0000 - rev 15731
Push 3821 by kjacobs@mozilla.com at Fri, 07 Aug 2020 22:18:04 +0000
Bug 1625791 - Call STAN_GetCERTCertificate to load CERTCertificate trust before caching. r=jcj,keeler When caching certificates, `td->cache->lock` must not be held when taking `slot->isPresentLock`. `add_cert_to_cache` holds then former when calling the sort function in `add_subject_entry`, which will [[ https://searchfox.org/mozilla-central/rev/a3b25e347e2c22207c4b369b99246e4aebf861a7/security/nss/lib/pki/certificate.c#266 | call ]] `STAN_GetCERTCertificate` -> `fill_CERTCertificateFields` when `cc->nssCertificate` [[ https://searchfox.org/mozilla-central/rev/a3b25e347e2c22207c4b369b99246e4aebf861a7/security/nss/lib/pki/pki3hack.c#923 | is NULL ]]. There are two problems with this: # `fill_CERTCertificateFields` may end up locking `slot->isPresentLock` (bad ordering, bug 1651564) # The above may happen followed by another attempt to lock `td->cache->lock`(deadlock, this bug). By calling `STAN_GetCERTCertificate` prior to the first lock of `td->cache->lock`, we can prevent the problematic call to `fill_CERTCertificateFields` later on, because `cc->nssCertificate` will already be filled. Differential Revision: https://phabricator.services.mozilla.com/D86423
41ecb7fe55461da66328758a08776f2291ea4d0b: Bug 1588941 - Send empty client cert msg when signature scheme selection fails. r=mt
Kevin Jacobs <kjacobs@mozilla.com> - Fri, 07 Aug 2020 16:36:31 +0000 - rev 15730
Push 3820 by kjacobs@mozilla.com at Fri, 07 Aug 2020 18:11:37 +0000
Bug 1588941 - Send empty client cert msg when signature scheme selection fails. r=mt `ssl3_CompleteHandleCertificateRequest` does essentially two things: 1) Calls the `getClientAuthData` hook for certificate selection, and 2) calls `ssl_PickClientSignatureScheme` to select an appropriate signature scheme when a cert is selected. If the first function returns SECFailure, we default to sending an empty certificate message. If the latter fails, however, this bubbles up as a [[ https://searchfox.org/mozilla-central/rev/56bb74ea8e04bdac57c33cbe9b54d889b9262ade/security/nss/lib/ssl/tls13con.c#2670 | fatal error ]] (and an assertion failure) on the connection. Importantly, the signature scheme selection can fail for reasons that should not be considered fatal - notably when an RSA-PSS cert is selected, but the token on which the key resides does not actually support PSS. This patch treats the failure to find a usable signature scheme as a "no certificate" response, rather than killing the connection entirely. Differential Revision: https://phabricator.services.mozilla.com/D85451
330bdab498a31ddd26d14585e3188aa9d4529d1b: Bug 1656981 - Use 64x64->128 multiply and MP_COMBA on x86_64 Mac. r=mt
Kevin Jacobs <kjacobs@mozilla.com> - Fri, 07 Aug 2020 15:31:25 +0000 - rev 15729
Push 3819 by kjacobs@mozilla.com at Fri, 07 Aug 2020 17:44:20 +0000
Bug 1656981 - Use 64x64->128 multiply and MP_COMBA on x86_64 Mac. r=mt This patch makes two MPI changes for MacOS: 1. Rename `mpi_amd64_gas.s` to `mpi_amd64_common.S` and add defines for macho64, allowing Intel Macs to take advantage of the 64x64->128 multiply code. 2. Define and use `NSS_USE_COMBA` on Intel Macs. Performance results with `rsaperf -n none -p 10 -e -x 65537` (default 2048-bit key): Before: `12629.12 operations/s. one operation every 79 microseconds` With 64x64->128 assembly: `29431.65 operations/s. one operation every 33 microseconds` With MP_COMBA and 64x64->128 assembly: `30332.99 operations/s. one operation every 32 microseconds` Differential Revision: https://phabricator.services.mozilla.com/D85783
07083076fc922da2ea019b72e0a640e343f65ecf: Bug 1656429 - Clang-format fixup, r=bustage
Kevin Jacobs <kjacobs@mozilla.com> - Fri, 07 Aug 2020 08:46:00 -0700 - rev 15728
Push 3818 by kjacobs@mozilla.com at Fri, 07 Aug 2020 15:47:30 +0000
Bug 1656429 - Clang-format fixup, r=bustage
b4a1c57eb569859170ef7b321039404f537f8fb9: Bug 1656429 - Correct RTT estimate used in anti-replay, r=kjacobs
Martin Thomson <mt@lowentropy.net> - Wed, 05 Aug 2020 00:17:52 +0000 - rev 15727
Push 3817 by mthomson@mozilla.com at Wed, 05 Aug 2020 00:20:47 +0000
Bug 1656429 - Correct RTT estimate used in anti-replay, r=kjacobs This was never a security problem, but the more time that passes between the handshake and sending a ticket, the more likely we are to reject 0-RTT. Eventually, 0-RTT only works if it is delayed in the network by a surprising amount. Differential Revision: https://phabricator.services.mozilla.com/D85540
afa38fb2f0b5d491a1bd0c26798ef0bdecd5ac8d: Bug 1656986 - special-case arm64 in detect_host_arch.py; r=jcj
Nathan Froyd <froydnj@mozilla.com> - Mon, 03 Aug 2020 20:43:00 +0000 - rev 15726
Push 3816 by jjones@mozilla.com at Mon, 03 Aug 2020 20:45:41 +0000
Bug 1656986 - special-case arm64 in detect_host_arch.py; r=jcj This case comes up when attempting to build NSS on ARM64 Mac. If we don't do this, we wind up detecting arm64 as "arm", with predictably bad consequences. Differential Revision: https://phabricator.services.mozilla.com/D85786
e6b77a9c417a53e51e6dc2e40e085fa4aa46a83b: Bug 1654142 - Add CPU feature detection for Intel SHA extension. r=kjacobs
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Fri, 31 Jul 2020 11:04:12 +0000 - rev 15725
Push 3815 by kaie@kuix.de at Fri, 31 Jul 2020 11:29:01 +0000
Bug 1654142 - Add CPU feature detection for Intel SHA extension. r=kjacobs Differential Revision: https://phabricator.services.mozilla.com/D84286
eb52747b7000210971b590ad06d041c5f4ef464b: Bug 1653975 - Set "all" as the default Makefile target r=jcj,rrelyea
Jan-Marek Glogowski <glogow@fbihome.de> - Wed, 29 Jul 2020 23:47:05 +0000 - rev 15724
Push 3814 by jjones@mozilla.com at Wed, 29 Jul 2020 23:49:33 +0000
Bug 1653975 - Set "all" as the default Makefile target r=jcj,rrelyea Just reorder the rules in manifest.mn, so all is again the first rule. This restores pre-3.53 Makefile defaults. Differential Revision: https://phabricator.services.mozilla.com/D85195
68b6eb7376897d6db3bb86337a3c99789d9687b8: Bug 1650702 - Use ARM's crypt extension for SHA1. r=kjacobs
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Wed, 29 Jul 2020 21:49:09 +0000 - rev 15723
Push 3813 by kjacobs@mozilla.com at Wed, 29 Jul 2020 21:52:17 +0000
Bug 1650702 - Use ARM's crypt extension for SHA1. r=kjacobs ARM Crypto extension has SHA1 acceleration. Using this, SHA1 is 3 times faster on ARMv8 CPU. The following data is AWS's a1 instance (Cortex-A72). Before ====== ``` # mode in opreps cxreps context op time(sec) thrgput sha1_e 954Mb 31M 0 0.000 10000.000 10.000 95Mb ``` After ===== ``` # mode in opreps cxreps context op time(sec) thrgput sha1_e 2Gb 94M 0 0.000 10000.000 10.000 288Mb ``` Differential Revision: https://phabricator.services.mozilla.com/D84125
4014c075a31b8d076d638d610f99fedc18b53e76: Fix more of the timeout issues on tests. (Drop expensive 4098 dh tests ).
Robert Relyea <rrelyea@redhat.com> - Mon, 27 Jul 2020 14:19:05 -0700 - rev 15722
Push 3812 by rrelyea@redhat.com at Mon, 27 Jul 2020 21:19:12 +0000
Fix more of the timeout issues on tests. (Drop expensive 4098 dh tests ).
0be91fa2217a979feb33f0032957b929dd8831ca: Bug 1648822 Add stricter validation of DH keys when in FIPS mode.
Robert Relyea <rrelyea@redhat.com> - Mon, 27 Jul 2020 11:00:02 -0700 - rev 15721
Push 3811 by rrelyea@redhat.com at Mon, 27 Jul 2020 18:00:08 +0000
Bug 1648822 Add stricter validation of DH keys when in FIPS mode. 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).
e6c6f1d2d544918ebc85bfb587c88ad304423948: Bug 1652729 - Add build flag to disable RC2 and relocate to lib/freebl/deprecated. r=kjacobs
Benjamin Beurdouche <bbeurdouche@mozilla.com> - Fri, 24 Jul 2020 17:16:51 +0000 - rev 15720
Push 3810 by kjacobs@mozilla.com at Mon, 27 Jul 2020 14:17:25 +0000
Bug 1652729 - Add build flag to disable RC2 and relocate to lib/freebl/deprecated. r=kjacobs Differential Revision: https://phabricator.services.mozilla.com/D83494
d98bbb6168f4ca2abd534e4c2fce56b7a5d1ad7e: Bug 1652032 Disable all freebl assembler code for MSVC arm64 r=rrelyea,bbeurdouche
Jan-Marek Glogowski <glogow@fbihome.de> - Mon, 27 Jul 2020 12:41:32 +0000 - rev 15719
Push 3809 by kjacobs@mozilla.com at Mon, 27 Jul 2020 14:12:59 +0000
Bug 1652032 Disable all freebl assembler code for MSVC arm64 r=rrelyea,bbeurdouche There are two places, where NSS tries to compile either x86_64 MSVC assembler or GCC aarch64 code, which will fail the build. And also drop the non-MSVC arch build flags for them. AFAI could identify, there isn't any armasm64 compatible asm code in the whole NSS library, so I don't even adapt AS for the build. The cross-build finishes this way. Differential Revision: https://phabricator.services.mozilla.com/D83137
2f2a0f76a48340770f9734c0d094fb7582310e55: Added tag NSS_3_55_RTM for changeset 6705eec655c8 NSS_3_55_BRANCH
J.C. Jones <jjones@mozilla.com> - Fri, 24 Jul 2020 08:10:40 -0700 - rev 15718
Push 3808 by jjones@mozilla.com at Fri, 24 Jul 2020 15:13:21 +0000
Added tag NSS_3_55_RTM for changeset 6705eec655c8
6705eec655c8237635f7dc830d743b26a7124650: Set version numbers to 3.55 final NSS_3_55_BRANCH NSS_3_55_RTM
J.C. Jones <jjones@mozilla.com> - Fri, 24 Jul 2020 08:10:32 -0700 - rev 15717
Push 3808 by jjones@mozilla.com at Fri, 24 Jul 2020 15:13:21 +0000
Set version numbers to 3.55 final
3f780d41ecbd4cf20ca93079c3ea6646ca6d78d1: Set version numbers to 3.56 beta
J.C. Jones <jjones@mozilla.com> - Fri, 24 Jul 2020 08:11:42 -0700 - rev 15716
Push 3807 by jjones@mozilla.com at Fri, 24 Jul 2020 15:12:32 +0000
Set version numbers to 3.56 beta
c25adfdfab34ddb08d3262aac3242e3399de1095: Bug 1636771 - Fix incorrect call to Chacha20Poly1305 by PKCS11. r=jcj,kjacobs,rrelyea NSS_3_53_BRANCH
Benjamin Beurdouche <bbeurdouche@mozilla.com> - Sat, 18 Jul 2020 00:13:38 +0000 - rev 15715
Push 3806 by jjones@mozilla.com at Thu, 23 Jul 2020 03:05:13 +0000
Bug 1636771 - Fix incorrect call to Chacha20Poly1305 by PKCS11. r=jcj,kjacobs,rrelyea Differential Revision: https://phabricator.services.mozilla.com/D74801
f282556e6cc7715f5754aeaadda6f902590e7e38: Bug 1636771 - Disable PKCS11 incremental mode for ChaCha20. r=kjacobs,rrelyea NSS_3_53_BRANCH
Benjamin Beurdouche <bbeurdouche@mozilla.com> - Sat, 18 Jul 2020 00:13:14 +0000 - rev 15714
Push 3806 by jjones@mozilla.com at Thu, 23 Jul 2020 03:05:13 +0000
Bug 1636771 - Disable PKCS11 incremental mode for ChaCha20. r=kjacobs,rrelyea Depends on D74801 Differential Revision: https://phabricator.services.mozilla.com/D83994
89733253df83ef7fe8dd0d49f6370b857e93d325: Bug 1631573: Remove unnecessary scalar padding in ec.c r=kjacobs,bbeurdouche NSS_3_53_BRANCH
Billy Brumley <bbrumley@gmail.com> - Mon, 20 Jul 2020 22:18:45 +0000 - rev 15713
Push 3806 by jjones@mozilla.com at Thu, 23 Jul 2020 03:05:13 +0000
Bug 1631573: Remove unnecessary scalar padding in ec.c r=kjacobs,bbeurdouche Subsequent calls to ECPoints_mul and ECPoint_mul remove this padding. Timing attack countermeasures are now applied more generally deeper in the call stack. Differential Revision: https://phabricator.services.mozilla.com/D82011
a7c4657f24201710bfd55482927e50b6e7955f25: Bug 1637222 - Enforce IV length check for DES. r=kjacobs,jcj NSS_3_53_BRANCH
Benjamin Beurdouche <bbeurdouche@mozilla.com> - Thu, 16 Jul 2020 21:31:45 +0000 - rev 15712
Push 3806 by jjones@mozilla.com at Thu, 23 Jul 2020 03:05:13 +0000
Bug 1637222 - Enforce IV length check for DES. r=kjacobs,jcj Differential Revision: https://phabricator.services.mozilla.com/D75774
(0) -10000 -3000 -1000 -300 -100 -50 -20 tip