Bug 1593141 adds a parameter to mozilla::pkix::TrustDomain::CheckRevocation.
This patch updates all TrustDomain implementations in mozilla-central to
reflect this.
Differential Revision: https://phabricator.services.mozilla.com/D52066
--HG--
extra : moz-landing-system : lando
This patch provides Delegated Credential information (authKeyBits and signature scheme) to CertVerifier such that we can enforce a policy check and disallow weak keys in the Delegated Credential.
This information is not passed from http3 - adding this will be done in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D47181
--HG--
rename : security/manager/ssl/tests/unit/test_delegated_credentials/delegated-selfsigned.key => security/manager/ssl/tests/unit/test_delegated_credentials/delegated.key
rename : security/manager/ssl/tests/unit/test_delegated_credentials/delegated-selfsigned.key.keyspec => security/manager/ssl/tests/unit/test_delegated_credentials/delegated.key.keyspec
extra : moz-landing-system : lando
During path building, mozilla::pkix filters out candidate certificates provided
by trust domains where the subject distinguished name does not match the issuer
distinguished name of the certificate it's trying to find an issuer for.
However, if there's a problem decoding the candidate issuer certificate,
mozilla::pkix will make a note of this error, regardless of if that certificate
was potentially a suitable issuer. If no trusted path is found, the error from
that unrelated certificate may ultimately be returned by mozilla::pkix,
resulting in confusion.
Before this patch, NSSCertDBTrustDomain could cause this behavior by blithely
passing every known 3rd party certificate to mozilla::pkix (other sources of
certificates already filter on subject distinguished name). This patch adds
filtering to 3rd party certificates as well.
Differential Revision: https://phabricator.services.mozilla.com/D48120
--HG--
extra : moz-landing-system : lando
Calling CERT_NewTempCertificate on an enterprise certificate is inefficient
because NSS tries (and fails) to find a copy of that certificate in its internal
data structures (which includes querying softoken, which involves hitting the
disk). We can avoid doing so for these certificates in
NSSCertDBTrustDomain::GetCertTrust because we already know what trust values
they should have (after checking the relevant blocklists).
Differential Revision: https://phabricator.services.mozilla.com/D45588
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
In bug 1056341 we introduced a search budget to mozilla::pkix to attempt to work
around the problem of having an extremely large search space given a set of
certificates all with the same subject and issuer distinguished names but
different public keys. In the end, though, there is probably no good value to
choose for the budget that is small enough to run quickly on the wide range of
hardware our users have and yet is large enough that we're confident won't break
someone's complicated pki setup (looking at you, the US federal government).
To address this, use the observation that as long as an intermediate can't *add*
information necessary to build a certificate chain (e.g. stapled SCTs), we
should never need a self-signed intermediate (as in, its own key verifies the
signature on it and its subject and issuer distinguished names are identical) to
build a trusted chain (since the exact same chain without that intermediate
should be valid). Given this, we simply skip all self-signed non-trust anchor
CA certificates during path building.
Differential Revision: https://phabricator.services.mozilla.com/D31368
--HG--
extra : moz-landing-system : lando
This updates cert_storage to be able to store certificates indexed by subject DN
for easy lookup by NSSCertDBTrustDomain during path building. This also updates
RemoteSecuritySettings to store newly-downloaded preloaded intermediates in
cert_storage.
Differential Revision: https://phabricator.services.mozilla.com/D27991
--HG--
extra : moz-landing-system : lando
Previously this functionality created a CryptoTask to do this work, but that
would cause a new thread to be created for each list of intermediates. This was
slow both because of all of the threads and because they could be scheduled
while other work was happening. Moving these tasks to the low-priority event
queue for threads in the certificate verification thread pool means no new
threads are created and the work only happens when these threads are idle
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D26630
--HG--
extra : moz-landing-system : lando
Apparently importing a certificate into the NSS certificate DB is slow enough to
materially impact the time it takes to connect to a site. This patch addresses
this by importing any intermediate certificates we want to cache from verified
connections on a background thread (so the certificate verification thread can
return faster).
Differential Revision: https://phabricator.services.mozilla.com/D24384
--HG--
extra : moz-landing-system : lando
Apparently importing a certificate into the NSS certificate DB is slow enough to
materially impact the time it takes to connect to a site. This patch addresses
this by importing any intermediate certificates we want to cache from verified
connections on a background thread (so the certificate verification thread can
return faster).
Differential Revision: https://phabricator.services.mozilla.com/D24384
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
As of bug 1514118, NSS is not the only place NSSCertDBTrustDomain looks for
issuer certificates. However, the initial implementation did not take into
account that NSSCertDBTrustDomain::FindIssuer would return early if NSS did not
find candidate issuers, resulting in unknown issuer errors for third party
roots. This patch fixes that bug by not returning early.
Differential Revision: https://phabricator.services.mozilla.com/D19058
--HG--
extra : moz-landing-system : lando
Before this patch, if the enterprise roots feature were enabled, nsNSSComponent
would gather any such roots and temporarily import them into NSS so that
CertVerifier could use them during path building and trust querying. This turned
out to be problematic in part because doing so would require unlocking the
user's key DB if they had a password. This patch implements a scheme whereby
nsNSSComponent can give these extra roots directly to CertVerifier, thus
bypassing NSS and any need to unlock/modify any DBs. This should also provide a
path forward for other improvements such as not repeatedly searching through all
certificates on all tokens, which has inefficiencies (see e.g. bug 1478148).
Differential Revision: https://phabricator.services.mozilla.com/D18156
--HG--
extra : moz-landing-system : lando
Before this patch, NSSCertDBTrustDomain::FindIssuer would iterate over its
candidate list (a CERTCertList) twice. This would have made it difficult to add
in candidate issuers from other sources (see e.g. bug 1514118, wherein the goal
is to bypass NSS' view of what certificates exist to facilitate third
party/enterprise roots). This patch reorganizes this function to make future
improvements easier.
Differential Revision: https://phabricator.services.mozilla.com/D16341
--HG--
extra : moz-landing-system : lando
Dana Keeler
Kevin Jacobs
Sean Feng
Marcus Burghardt
Kershaw Chang
Barret Rennie
Dorel Luca
Oana Pop Rus
arthur.iakab
Dragana Damjanovic
Moritz Birghan
Gurzau Raul
Myk Melez
Sylvestre Ledru
Csoregi Natalia
Narcis Beleuzu
shindli
Jeff Walden
Mark Goodwin
Andreea Pavel
Mike Hommey
Ehsan Akhgari