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
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
In reimplementing the OCSP fetching code in bug 1456489, we improperly
translated an assertion that relied on the nullness of a pointer to rely on the
length of a data structure that was populated by reference. It turns out that
this made the assertion invalid because we could return a successful result and
have filled the data structure with zero-length data and it still would be valid
to operate on (the decoding code returns a malformed input result in this case).
To fix this, we can simply remove the assertion. This patch also adds a test to
exercise this case.
Differential Revision: https://phabricator.services.mozilla.com/D8883
--HG--
extra : moz-landing-system : lando
Several source files use DLL_PREFIX/DLL_SUFFIX defines, and they all set
them in moz.build using `DEFINES`. This is problematic for the WSL
build because the quoting gets lost somewhere between bash and cl.exe.
We cannot simply set them globally in moz.configure because their
stringified definitions would conflict with the `set_config` of
DLL_PREFIX/DLL_SUFFIX. Therefore, we globally define
MOZ_DLL_PREFIX/MOZ_DLL_SUFFIX and change all define-related uses of
DLL_PREFIX/DLL_SUFFIX to use their MOZ-equivalents instead.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
nsNSSComponent startup and shutdown would be simpler if there were no direct
dependencies on localized strings. This patch removes a dependency on the
localized name of the builtin roots module by hard-coding the name internally
and then mapping it to/from the localized version as appropriate.
MozReview-Commit-ID: 30kbpWFYbzm
--HG--
extra : rebase_source : 3d384af5a9fa45d5ac1f78e1fcb0dd9e4b94267d
Per Bug 1437754 comment 10, the pref security.pki.distrust_ca_policy makes more
sense as a bitmask than a state. To permit future nuance, let's go ahead and do
that before people start implementing atop Bug 1456112.
This does permit both 0b10 and 0b11 to enable the functionality for Firefox 63.
--HG--
extra : transplant_source : %84%AF%89%E0%89dT%01%10%84%A0%3B%A5%28%2A%D3%E1%B0%0D%E7
OCSP requests cannot be performed on the main thread. If we were to wait for a
response from the network, we would be blocking the main thread for an
unnaceptably long time. If we were to spin the event loop while waiting (which
is what we do currently), other parts of the code that assume this will never
happen (which is essentially all of them) can break.
As of bug 867473, no certificate verification happens on the main thread, so no
OCSP requests happen on the main thread. Given this, we can go ahead and
prohibit such requests.
Incidentally, this gives us an opportunity to improve the current OCSP
implementation, which has a few drawbacks (the largest of which is that it's
unclear that its ownership model is implemented correctly).
This also removes OCSP GET support. Due to recent OCSP server implementations
(namely, the ability to cache OCSP POST request responses), OCSP GET is not a
compelling technology to pursue. Furthermore, continued support presents a
maintenance burden.
MozReview-Commit-ID: 4ACDY09nCBA
--HG--
extra : rebase_source : 072564adf1836720e147b8250afca7cebe4dbf62
This adds another preference (DistrustSymantecRootsRegardlessOfDate == 2) that
stops permitting certificates issued after 1 June 2016, and updates the test to
check it.
--HG--
extra : transplant_source : %F1%DE%16m%F2%DD%A8Ei%EF%B4%CAo%BF%8D%A6%A6%5E%D4%89
Bug 1441223 added MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED to be
emitted when we hit certificates affected by the Symantec distrust.
Since some sites have multiple certificate trust paths possible, sometimes
SEC_ERROR_UNKNOWN_ISSUER is emitted instead of the more specific error.
This patch uses a flag to ensure that the specific error is emitted out of the
Cert Verifier.
--HG--
extra : rebase_source : a961d2e713ae342222d85dff6f83ed3bcaa8006b
Certificate verification failures that result from additional policy constraint
failures now use the error code
"MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED" (also known as
"Result::ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED", depending on the context).
MozReview-Commit-ID: 9rE7gRBapRF
--HG--
extra : rebase_source : 9a60900a86f9eebab58b973f3e8f776b2481a1ff
This adds the pref "security.pki.distrust_ca_policy" which, if set to 1,
enforces the graduated distrust from Bug 1409257, and if set to 0 (as it is in
this patch) disables that distrust.
This pref is intended to outlast the Symantec distrust, and instead be able to
extend to enable/disable future root policy actions. It would need its own
tests for that, in the future.
MozReview-Commit-ID: BAZfkapysfX
--HG--
extra : rebase_source : 02b00aa486e9f8efb81b32d38d80db5cae86bc6e
This adds the 4 digicert CAs to our whitelist as specified in Google's details
on the Chromium version of this plan [1].
[1] c022914eb2/net/data/ssl/symantec/README.md
MozReview-Commit-ID: BR7t1UheKeS
--HG--
rename : security/certverifier/TrustOverride-AppleGoogleData.inc => security/certverifier/TrustOverride-AppleGoogleDigiCertData.inc
extra : rebase_source : 406e42e805b3778ccce7ee85b18d5dea93e32b95
Because of the DigiCert-controlled sub-CAs and managed-CAs identified as also
needing to be whitelisted [1], and that those CAs are using an increasing number
of certificates all with different Subjects (but identical public keys) [2][3],
we will have to whitelist on SPKI rather than subject DN.
This makes the security/manager/ssl/tests/unit/test_symantec_apple_google.js
integration test different, as it now uses a real Google certificate that is
in the whitelist with only a cert verification rather than a full connection
test.
This patch does not add the DigiCert SPKIs to the list; I will do that in its
own patch.
[1] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
[2] https://chromium-review.googlesource.com/c/chromium/src/+/916730
[3] https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
MozReview-Commit-ID: 4qVeogDbSb
--HG--
extra : rebase_source : abbdd432b190d059a3b2ceeccf89b85a12c214dd
The algorithm from https://hg.mozilla.org/mozilla-central/rev/595e27212723
(Bug 1409259) is adapted in this patch from nsNSSCallbacks into the TrustDomain
decisions.
This patch does not change the algorithm to use SPKI matching, nor add the
additional whitelisted intermediates from DigiCert; that will be done in a
separate commit.
This patch also does not update the pre-existing browser chrome test.
MozReview-Commit-ID: 1PdCAqo71bI
--HG--
extra : rebase_source : f1c6d00e16682f9303b8b2bfdf1fe5773c515ac5
This adds the 4 digicert CAs to our whitelist as specified in Google's details
on the Chromium version of this plan [1].
[1] c022914eb2/net/data/ssl/symantec/README.md
MozReview-Commit-ID: BR7t1UheKeS
--HG--
rename : security/certverifier/TrustOverride-AppleGoogleData.inc => security/certverifier/TrustOverride-AppleGoogleDigiCertData.inc
extra : rebase_source : 328a3b03a2c40fdf77497430481aa01df6f0059d
Because of the DigiCert-controlled sub-CAs and managed-CAs identified as also
needing to be whitelisted [1], and that those CAs are using an increasing number
of certificates all with different Subjects (but identical public keys) [2][3],
we will have to whitelist on SPKI rather than subject DN.
This makes the security/manager/ssl/tests/unit/test_symantec_apple_google.js
integration test different, as it now uses a real Google certificate that is
in the whitelist with only a cert verification rather than a full connection
test.
This patch does not add the DigiCert SPKIs to the list; I will do that in its
own patch.
[1] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
[2] https://chromium-review.googlesource.com/c/chromium/src/+/916730
[3] https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
MozReview-Commit-ID: 4qVeogDbSb
--HG--
extra : rebase_source : 6912963abe7d05bf2a944fae1209512650763032
The algorithm from https://hg.mozilla.org/mozilla-central/rev/595e27212723
(Bug 1409259) is adapted in this patch from nsNSSCallbacks into the TrustDomain
decisions.
This patch does not change the algorithm to use SPKI matching, nor add the
additional whitelisted intermediates from DigiCert; that will be done in a
separate commit.
This patch also does not update the pre-existing browser chrome test.
MozReview-Commit-ID: 1PdCAqo71bI
--HG--
extra : rebase_source : bc0b1b419dc340a033008d9e9e3b443a2751d5d1
This commit reworks PublicKeyPinningService::ChainHasValidPins and
PublicKeyPinningService::EvalChain to use nsNSSCertList directly. It also
updates nsSiteSecurityService::ProcessPKPHeader. This will be made more
efficient in Bug 1406854, where the call to VerifySSLServerCert gets replaced
with one to GetSucceededCertChain. (Such a change is premeature now because
before Bug 731478 lands this would lead to a session resumption regression
causing pins to not be set properly, which is triggered repeatedly in the
xpcshell tests.)
MozReview-Commit-ID: 1l186n1lXLH
--HG--
extra : rebase_source : 88e40bbf41b324ece762abfa84a758380102e199
extra : histedit_source : addcddf253c2901a25b29f65046908f52df61345
This change is to use the higher-level structure nsNSSCertList when checking
IsChainValid so that we can use the more powerful (and tested) methods of that
object instead of the ad-hoc iterators.
This will also permit the Symantec Distrust code in Bug 1434300 to use these
methods, which keeps the code the same from the earlier Bug 1409259.
MozReview-Commit-ID: B5KmDa1JLE
--HG--
extra : rebase_source : 397d3ef7189eb6f81a1ceaf920464d9e842a8981
extra : histedit_source : 26b22257cb5fcc3389630dd0a1aba24095c46158
MOZPSM_NSSDBDIR_OVERRIDE was added in bug 462919 for integration with xulrunner
applications. Upcoming changes we're aiming to make with how PSM handles NSS and
the certificate/key databases (e.g. making the sqlite-backed implementation
mandatory) mean we have to take this feature into account. xulrunner isn't
supported any longer. Searching the web for "MOZPSM_NSSDBDIR_OVERRIDE" yields
two kinds of results: mozilla-central source code and a man page for nss-gui,
which it seems is the only project that ever made use of
MOZPSM_NSSDBDIR_OVERRIDE (and hasn't been updated since 2013, from what I can
tell). I think it's fair to conclude that this isn't a widely-used (let alone
known) feature. To make development easier, we should remove it.
MozReview-Commit-ID: 56vcTYSzDPq
--HG--
extra : rebase_source : 683a65bcd79182c04524562bc26ed5925f5d902b
Since we'll need the same structs and mechanisms to work with the Symantec roots,
this patch makes the matching function generic and moves it into a new header,
"TrustOverrides.h".
This also moves the GlobalSignData out into "TrustOverride-GlobalSignData.inc"
and the WoSign/StartCom to "TrustOverride-StartComAndWoSignData.inc".
MozReview-Commit-ID: 2yWcvrngKwr
--HG--
rename : security/certverifier/StartComAndWoSignData.inc => security/certverifier/TrustOverride-StartComAndWoSignData.inc
extra : rebase_source : 26d86765277563ddafd5bbf0f4372ccdb280d062
NSS command-line utilities may add a built-in root certificate module with the
name "Root Certs" if run on a profile that has a copy of the module file (which
is an unexpected configuration in general for Firefox). This can cause breakage.
To work around this, PSM now simply deletes any module named "Root Certs" at
startup. In an effort to prevent PSM from deleting unrelated modules
coincidentally named "Root Certs", we also prevent the user from using the
Firefox UI to name modules "Root Certs".
MozReview-Commit-ID: ABja3wpShO9
--HG--
extra : rebase_source : cfc62fb3fabf491a72f009601f3ec6973244642e
Bug 1364159 introduced an optimization that attempted to avoid reading from the
user's cached certificate database as much as possible when building a verified
certificate chain. Unfortunately this had the side-effect of not preferring root
certificates in path building, which can result in unnecessarily long chains
(which rather defeats the purpose, since it means more signature verifications).
This patch reverts the functionality changes from that bug but keeps the test
that was added (the test didn't directly test the functionality changes - it's
more of a check that path building will query the cached certificate db when
necessary).
MozReview-Commit-ID: I56THTLUytH
--HG--
extra : rebase_source : 7db9597e25b98942450840519d707046cc660781
In the future, bug 1377940 will make the sqlite-backed databases the default,
but until we're sure this will stick we want to be able to control this with a
Firefox-only change. The use of a preference to configure which format to use
will hopefully allow us to restore the old behavior quickly and relatively
safely if necessary. Note that doing this should be done with care; any changes
made in the sqlite databases after upgrade migration will not be reflected if
we need to go back to the old database format. Thus, user data (imported CAs,
client certificates, and keys) can be lost.
MozReview-Commit-ID: tkovdiCU9v
--HG--
extra : rebase_source : e74358bd65afb5844fa8fc5b729eba2bbc5bb2db
The sqlite-backed NSS database implementation requires explicitly setting some
kind of pin (password, really). To maintain behavior compatibility with the old
database implementation, we set the pin to the empty string as necessary.
Previously this would only happen on Android (NSS_DISABLE_DBM builds), but
because we're moving towards using the sqlite-backed implementation on all
platforms, we should enable this code everywhere and move it to a more central
location.
This also fixes some now-unnecessary test behavior.
MozReview-Commit-ID: KKtxmvOZt78
--HG--
extra : rebase_source : 0de061928bf63b62386a4e244b326610d32cd122
In a profile, loading the loadable roots PKCS#11 module (i.e. the built-in root
CA module) accounted for about 60% of the time to initialize PSM/NSS. Since we
only need the roots module loaded when we're actually looking for an issuing
certificate or querying a certificate's trust, we can do the load
asynchronously (where it hopefully finishes before we actually need it, because
otherwise we'll have to wait anyway).
MozReview-Commit-ID: JyY6NtpQAUj
--HG--
extra : rebase_source : f63a697b18a409dd042289afa2b727b09f81f19f
As a result of CNNIC issuing an unconstrained intermediate certificate that
misissued an end-entity certificate for google.com (see bug 1146026 and
bug 1177209), we implemented a system that would in theory enable Firefox to
continue to trust certificates that were valid at the time but not newly issued
certificates. This consisted of a whitelist added in bug 1151512. The CNNIC
roots have since been removed from NSS in bug 1380868. We can now remove the
whitelist in Firefox.
MozReview-Commit-ID: 7VXOuvwzbct
--HG--
extra : rebase_source : 20e6e39c40417a9b7f2962e06cf9de85e3e08ee8
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
Dana Keeler
Narcis Beleuzu
shindli
Jeff Walden
Mark Goodwin
Andreea Pavel
Sylvestre Ledru
Franziskus Kiefer
Ted Mielczarek
Emilio Cobos Álvarez
J.C. Jones
Sebastian Hengst
Nicholas Nethercote