зеркало из https://github.com/mozilla/gecko-dev.git
5637d1775c
2020-08-07 Kevin Jacobs <kjacobs@mozilla.com> * lib/pki/tdcache.c: 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/a3b25e347e2c22207c4b369b99 246e4aebf861a7/security/nss/lib/pki/certificate.c#266 | call ]] `STAN_GetCERTCertificate` -> `fill_CERTCertificateFields` when `cc->nssCertificate` [[ https://searchfox.org/mozilla-central/rev/a3 b25e347e2c22207c4b369b99246e4aebf861a7/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. [c06f22733446] [tip] * gtests/ssl_gtest/ssl_auth_unittest.cc, lib/ssl/ssl3con.c: 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/56bb74e a8e04bdac57c33cbe9b54d889b9262ade/security/nss/lib/ssl/tls13con.c#26 70 | 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. [41ecb7fe5546] * lib/freebl/Makefile, lib/freebl/freebl_base.gypi, lib/freebl/mpi/mpi_amd64_common.S, lib/freebl/mpi/mpi_amd64_gas.s: 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` [330bdab498a3] * lib/ssl/sslimpl.h: Bug 1656429 - Clang-format fixup, r=bustage [07083076fc92] 2020-08-05 Martin Thomson <mt@lowentropy.net> * gtests/ssl_gtest/ssl_0rtt_unittest.cc, gtests/ssl_gtest/tls_connect.cc, lib/ssl/ssl3exthandle.c, lib/ssl/sslimpl.h, lib/ssl/tls13con.c, lib/ssl/tls13replay.c: 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. [b4a1c57eb569] Differential Revision: https://phabricator.services.mozilla.com/D86454 |
||
|---|---|---|
| .. | ||
| apps | ||
| certverifier | ||
| ct | ||
| mac/hardenedruntime | ||
| manager | ||
| nss | ||
| sandbox | ||
| .eslintrc.js | ||
| generate_certdata.py | ||
| generate_mapfile.py | ||
| moz.build | ||
| nss.symbols | ||