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
The NSS Base64 functions are less safe and convenient to use than the XPCOM ones.
They're also an unnecessary dependency on NSS.
The NSS Base64 functions behave slightly differently than the XPCOM ones:
1. ATOB_ConvertAsciiToItem() / NSSBase64_DecodeBuffer() silently ignore invalid
characters like CRLF, space and so on. Base64Decode() will return an error
if these characters are encountered.
2. BTOA_DataToAscii() will produce output that has CRLF inserted every 64
characters. Base64Encode() doesn't do this.
For the reasons listed below, no unexpected compatibility issues should arise:
1. AppSignatureVerification.cpp already filters out CRLF and spaces for Manifest
and Signature values before decoding.
2. ExtendedValidation.cpp is only given what should be valid hard-coded input to
decode.
3. ContentSignatureVerifier.cpp already splits on CRLF for when it needs to
decode PEM certs. Spaces shouldn't be likely.
For Content-Signature header verification, examination of real input to a
running instance of Firefox suggests CRLF and spaces will not be present in
the header to decode.
4. nsCryptoHash.cpp encode is affected, but we actually don't want the CRLF
behaviour.
5. nsDataSignatureVerifier.cpp decode is affected, but we add whitespace
stripping to maintain backwards compatibility.
6. nsKeygenHandler.cpp encode is affected, but the previous CRLF behaviour was
arguably a bug, since neither WHATWG or W3C specs specified this.
MozReview-Commit-ID: IWMFxqVZMeX
--HG--
extra : rebase_source : 4863b2e5eabef0555e8e1ebe39216d0d9393f3e9
verifySignedManifestAsync() was added in Bug 1059216 to support Trusted Hosted
Apps.
However, Bug 1196988 removed THA and no add-ons use this method, so there's no
point in keeping it around.
MozReview-Commit-ID: 6xBRxvRZfjh
--HG--
extra : rebase_source : 5b8cf9c5863187b55325a8f9929bbe52c6478ec5
CERT_AddTempCertToPerm and CERT_ImportCerts (when called with keepCerts=true)
internally use PK11_GetInternalKeySlot. The current plan for making NSS always
available involves initializing it in memory-only mode and later opening the
user's certificate and key databases. Doing so means that
PK11_GetInternalKeySlot will not return the right token, so we can't rely on
functions that make use of it internally. For now we'll simply use equivalent
functions that take an explicit PK11SlotInfo argument and pass in the current
internal token. A later patch will change all places where PSM and Gecko use the
internal token to use the correct token.
MozReview-Commit-ID: CpSo5dIkyVW
--HG--
extra : rebase_source : 4f6e1707b34cb8dcf5e89cf3620c2d76fea39c82
Dana Keeler
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
Cykesiopka
Jonathan Hao
Ted Mielczarek