To evaluate the performance impact of CRLite over OCSP, we need to measure when
CRLite is (presumably) faster and by how much. To do this, we measure the
duration of the respective operations and when both occur for the same
verification, we make a note in the appropriate histogram of how much faster
one was than the other.
data-review+ was already given in bug 1488865 comment 5
Differential Revision: https://phabricator.services.mozilla.com/D56508
--HG--
extra : moz-landing-system : lando
This patch implements CRLite lookups for TLS server certificate revocation
information in telemetry-only mode. It adds a new preference
"security.pki.crlite_mode" to control the behavior of this feature. Setting
this preference to 0 disables it completely. Setting it to 1 enables telemetry
collection only (the default). Setting it to 2 enables enforcing revocation
information found via CRLite.
Differential Revision: https://phabricator.services.mozilla.com/D54040
--HG--
rename : third_party/rust/bit_reverse/LICENSE-APACHE => third_party/rust/rental/LICENSE-APACHE
rename : third_party/rust/bit-vec/LICENSE-MIT => third_party/rust/rental/LICENSE-MIT
extra : moz-landing-system : lando
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
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
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
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
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
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
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
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
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
CERT_CreateSubjectCertList is not an inexpensive function call, since it
enumerates the certificate database (i.e. reads from disk a lot). If we're
verifying for a TLS handshake, however, we should already have in memory a
certificate chain sent by the peer (there are some cases where we won't, such as
session resumption (see bug 731478)). If we can, we should use those
certificates before falling back to calling CERT_CreateSubjectCertList.
MozReview-Commit-ID: ASjVGsELb1O
--HG--
extra : rebase_source : 1efc635d4a98079c87f77ef3794e4b2f20eec59f
The default OCSP timeout for soft-fail DV is still 2 seconds. This patch makes
it configurable on the interval (0, 5] seconds.
The default OCSP timeout for EV and hard-fail DV is still 10 seconds. This patch
makes it configurable on the interval (0, 20] seconds.
MozReview-Commit-ID: CPd8pwYrJhj
--HG--
extra : rebase_source : 45bd7d06ea013f0a776ea18be9408dedb18271d8
(adapted from bug 1349762 comment 0)
Google Trust Services (GTS) recently purchased two roots from GlobalSign that
are both enabled for EV treatment: "GlobalSign Root CA - R2" and "GlobalSign ECC
Root CA - R4".
However, GTS does not have an EV audit, so we are going to turn off EV treatment
for both of those root certificates.
But "GlobalSign Root CA - R2" has intermediate cert "GlobalSign Extended
Validation CA - SHA256 - G2" that continues to be controlled by GlobalSign, to
be used to migrate their customers off dependence on that root.
This patch removes EV treatment for "GlobalSign ECC Root CA - R4". It also
removes EV treatment for all chains rooted in "GlobalSign Root CA - R2" unless
the "GlobalSign Extended Validation CA - SHA256 - G2" intermediate is in the
chain.
MozReview-Commit-ID: Ej9L9zTwoPN
--HG--
extra : rebase_source : 575f1a48646cf728d879d0cf53c888654e4a32ad
The PR_SetError() + PR_GetError() pattern is error prone and unnecessary.
Also fixes Bug 1254403.
MozReview-Commit-ID: DRI69xY4vxC
--HG--
extra : rebase_source : aa07c0dfb5cc2a203e772b415b7a75b27d9bad3c
The (more) modern Mozilla string classes can be used instead, which at the very
least provide built in automatic memory management and performance improvements.
MozReview-Commit-ID: 4l2Er5rkeI0
--HG--
extra : transplant_source : %A1%16%AB%02m%CA%25HfW%40%96Mq%0D%F0%91%9C%99%29
ScopedPK11SlotInfo is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
Also changes PK11SlotInfo parameters of various functions to make ownership more
explicit, and replaces some manual management of PK11SlotInfo pointers.
MozReview-Commit-ID: JtNH2lJsjwx
--HG--
extra : rebase_source : 9d764e0dd3a1f2df14c16f8f14a3c5392770c9a1
ScopedCERTCertList is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
Also changes CERTCertList parameters of various functions to make ownership more
explicit.
MozReview-Commit-ID: EXqxTK6inqy
--HG--
extra : transplant_source : %9B%A9a%94%D1%7E%2BTa%9E%9Fu%9F%02%B3%1AT%1B%F1%F6
Before this patch, we were measuring where SHA-1 was being used in TLS
certificates: nowhere, in end-entities, in intermediates, or in both. However,
the possible SHA-1 policies don't differentiate between end-entities and
intermediates and instead depended on whether or not each certificate has a
notBefore value after 2015 (i.e. >= 0:00:00 1 January 2016 UTC). We need to
gather telemetry on the possible policy configurations.
--HG--
extra : rebase_source : 301c821c8de16ffb924cd198dd0a4d3139536019