Firefox sometimes caches intermediate certificates from verified connections in
case they are useful in the future. This operation involves modifying the NSS
cert database, and so should only be done on the socket thread (ideally when it
is idle).
Differential Revision: https://phabricator.services.mozilla.com/D106230
CLOSED TREE
Backed out changeset 3c771d45563a (bug 1684040)
Backed out changeset 76e79151d53c (bug 1684040)
Backed out changeset 7a993eb7bfde (bug 1684040)
nsNSSComponent has a background task queue that can be used for importing
intermediates from TLS connections instead of using the certificate
verification thread pool.
This patch also addresses places where PSM was directly accessing the isperm
member of CERTCertificate, which is protected by a lock.
Differential Revision: https://phabricator.services.mozilla.com/D86051
PSM internals are currently tightly-copuled with NSS data types. In many cases
this is unnecessary, because PSM often needs only a sequence of bytes (in the
case of certificates, for example). This tight coupling can also have
performance and architectural impacts. For example, thread contention for NSS
resources has caused performance issues in the past. This patch starts the
process of avoiding using these types as much as possible in PSM.
More specifically, RootCABinNumber can take a Span<uint8_t> instead of a
SECItem. Instead of taking a PK11SlotInfo (which essentially requires having a
CERTCertificate), we can use PK11_FindEncodedCertInSlot to see if the
certificate exists on a small number of specific slots to achieve the same
effect as before. Doing this should eventually allow us to avoid creating a
CERTCertificate, which implicitly involves searching all slots on all modules.
Differential Revision: https://phabricator.services.mozilla.com/D83682
Before this patch, Firefox would call CERT_FindUserCertsByUsage to gather all
known client certificates. This function enumerates all known certificates and
filters some of them out. When there are many certificates that are not client
certificates (e.g. roots and intermediates), this is inefficient. Since this is
likely to be the case for most users, this patch optimizes this task by instead
first searching for private keys and then gathering all certificates that have
corresponding public keys.
Differential Revision: https://phabricator.services.mozilla.com/D46187
--HG--
extra : moz-landing-system : lando
This patch does not change the existing servers to use the new mechanism, rather
attempting to be minimalist. I filed Bug 1569222 for that.
Differential Revision: https://phabricator.services.mozilla.com/D39518
--HG--
extra : moz-landing-system : lando
SSLTokensCache is a simple memory only storage for resumption tokens which are get and set using API for external TLS session caches in NSS.
Differential Revision: https://phabricator.services.mozilla.com/D29465
--HG--
extra : moz-landing-system : lando
This implements an API in `nsIOSKeyStore.idl` and `OSKeyStore.cpp` to encrypt and decrypt bytes with a key that is stored in the OS key store.
There are two OS adapters in this patch.
Libsecret is used on Linux if available.
The NSS key store is used as fallback if no OS specific key store is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D1858
--HG--
extra : rebase_source : 99d7d646968a46a13ffa61885bb246f6d3e443e4
Apparently a prehistoric server implementation would send a
certificate_authorities field that didn't include the outer DER SEQUENCE tag, so
PSM attempted to detect this and work around it. Telemetry indicates this is
unnecessary now: https://mzl.la/2Lbi1Lz
--HG--
extra : rebase_source : 6669586d657efb243070a4ceb231583b40823543
extra : amend_source : e87f7c84c6c1a51637914bde5950268409b70571
Before this patch, mozilla::pkix gtests would generate a public/private key pair
and stash it in a global variable. Since this wasn't part of XPCOM nor tracked
by the PSM/NSS shutdown machinery, it wouldn't get released at the appropriate
time. The solution to this is to generate the key and then essentially export it
as data, so no NSS objects are held alive. Since NSS considers private keys
stored in the persistent database sensitive and won't export them in the clear,
we "encrypt" the key material with an empty password so we can import it when
necessary. (While the gtests don't use persistent keys, the test utilties in the
gtests are also used by some xpcshell tests that do use persistent keys, hence
the need to encrypt the key material.)
--HG--
extra : rebase_source : df10c25a462a3ba0396f5ba4a43a52fb924548ff
extra : amend_source : d95722891e49a99c471046cd9c758e914a02838e
Modified from bug 1248818 comment 11:
Before this patch, if a user had a smart card (PKCS#11 device) with removable
slots, Firefox would launch a thread for each module and loop, calling
SECMOD_WaitForAnyTokenEvent to be alerted to any insertions/removals. At
shutdown, we would call SECMOD_CancelWait, which would cancel any waiting
threads. However, since that involved calling 3rd party code, we really had no
idea if these modules were behaving correctly (and, indeed, they often weren't,
judging by the shutdown crashes we were getting).
The real solution is to stop relying on PKCS#11, but since that's unlikely in
the near future, the next best thing would be to load these modules in a child
process. That way, misbehaving modules don't cause Firefox to hang/crash/etc.
That's a lot of engineering work, though, so what this patch does is avoids the
issue by never calling SECMOD_WaitForAnyTokenEvent (and thus we never have to
call SECMOD_CancelWait, etc.). Instead, every time Firefox performs an operation
that may be affected by a newly added or removed smart card, it first has NSS
refresh its view of any removable slots. This is similar to how we ensure the
loadable roots module has been loaded (see bug 1372656).
MozReview-Commit-ID: JpmLdV7Vvor
--HG--
extra : rebase_source : d3503d19fa9297106d661a017a38c30969fa39b4
Calling VFY_VerifyDigestDirect causes the provided SECKEYPublicKey to be
reimported to the softoken regardless of if it already exists on it. EC keys
must be verified upon import (to see if the point is on the curve to avoid some
small subgroup attacks), and so repeatedly doing this with a static key (say,
for example, a key corresponding to a built-in certificate transparency log) is
inefficient. This patch alters the certificate transparency implementation to
import these keys each once and then use PK11_Verify for ECDSA signature
verification, which doesn't have the same drawback.
Since this change causes CertVerifier to hold an NSS resource (via its
MultiLogCTVerifier having a list of CTLogVerifier, each of which now has a
SECKEYPublicKey), nsNSSComponent has to make sure it goes away before shutting
down NSS. This patch ensures this happens in nsNSSComponent::ShutdownNSS().
MozReview-Commit-ID: 6VSmz7S53y2
--HG--
extra : rebase_source : 4994db9de80a6c1aec3d7e322ff30d040140ce92
John Schanck
longsonr
Benjamin Beurdouche
Simon Giesecke
Dana Keeler
Butkovits Atila
Kershaw Chang
Mihai Alexandru Michis
Julien Cristau
Benjamin Beurdouche
Andy Grover
Dragana Damjanovic
J.C. Jones
Ehsan Akhgari
Michal Novotny
Kai Engert
Byron Campen [:bwc]
Robert Helmer
Cosmin Sabou
Gurzau Raul
Franziskus Kiefer
Felipe Gomes
Andreea Pavel
Kai Engert
Sajjad Arshad