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 patch does a few things:
1) It removes the symantecRoot and symantec_affected certs from build/pgo/certs'
DB.
2) It upgrades that DB from the old format to SQLite (and this 8/3 to 9/4).
3) It adds a new cert "imminently_distrusted" to that DB for the bc test.
4) It changes the Subject of the immient distrust test to only have the CN
field: this is because certutil reorders C to come after CN, and just like
with the real Symantec certs, I had put C first. So rather than deal with
importing the end entity for the pgo tests, I decided to just make things
simple and change the tested subject.
5) Finally, it re-enables the test that was disabled in Bug 1434300.
MozReview-Commit-ID: Bt2RKyInJje
--HG--
rename : build/pgo/certs/cert8.db => build/pgo/certs/cert9.db
rename : build/pgo/certs/key3.db => build/pgo/certs/key4.db
extra : rebase_source : efceb67ae16f0af617bbd8bec201d52eee0f467d
This is the test originally from Bug 1434300 that was pulled due to
Bug 1433015.
MozReview-Commit-ID: IEPCRVdS2v4
--HG--
extra : rebase_source : 843222f36b9fffe73cdf02aebb3f263897a943de
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
This modifies crtshToDNStruct.py to be able to produce SPKI or DN-based lists,
and adds a SPKI-search method to TrustOverrideUtils.h.
This also regenerates the TrustOverride files to use the new script.
MozReview-Commit-ID: BhMoJbYXs7Y
--HG--
rename : security/manager/tools/crtshToDNStruct/crtshToDNStruct.py => security/manager/tools/crtshToIdentifyingStruct/crtshToIdentifyingStruct.py
rename : security/manager/tools/crtshToDNStruct/requirements.txt => security/manager/tools/crtshToIdentifyingStruct/requirements.txt
extra : rebase_source : 9ae4999ceea2d4092119fe81b787c4d66a5e17b1
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 patch does a few things:
1) It adds a permament test mechanism for the "imminent distrust" trust status
in nsNSSCallbacks: a simple xpcshell test to exercise a clause in the imminent
distrust logic in nsNSSCallbacks' IsCertificateDistrustImminent method.
2) This test removes test_symantec_apple_google_unaffected.js as its
functionality is rolled into the new test_imminent_distrust.js.
3) It updates the Symantec imminent distrust warning algorithm to remove the
validity date exception; this warns of the upcoming distrust for those affected
certs in Firefox 63.
This patch does not attempt to edit the browser chrome test that checks the
console; that is a subsequent patch.
MozReview-Commit-ID: 1HyVLfmEOP7
--HG--
extra : rebase_source : 3955e3dcd9a21421105d97bd65d3965041de9b8c
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
This modifies crtshToDNStruct.py to be able to produce SPKI or DN-based lists,
and adds a SPKI-search method to TrustOverrideUtils.h.
This also regenerates the TrustOverride files to use the new script.
MozReview-Commit-ID: BhMoJbYXs7Y
--HG--
rename : security/manager/tools/crtshToDNStruct/crtshToDNStruct.py => security/manager/tools/crtshToIdentifyingStruct/crtshToIdentifyingStruct.py
rename : security/manager/tools/crtshToDNStruct/requirements.txt => security/manager/tools/crtshToIdentifyingStruct/requirements.txt
extra : rebase_source : 335d7fc05fa35fbb54ee7ee518b9f4e0c7a00159
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 patch does a few things:
1) It adds a permament test mechanism for the "imminent distrust" trust status
in nsNSSCallbacks: a simple xpcshell test to exercise a clause in the imminent
distrust logic in nsNSSCallbacks' IsCertificateDistrustImminent method.
2) This test removes test_symantec_apple_google_unaffected.js as its
functionality is rolled into the new test_imminent_distrust.js.
3) It updates the Symantec imminent distrust warning algorithm to remove the
validity date exception; this warns of the upcoming distrust for those affected
certs in Firefox 63.
This patch does not attempt to edit the browser chrome test that checks the
console; that is a subsequent patch.
MozReview-Commit-ID: 1HyVLfmEOP7
--HG--
extra : rebase_source : 48c9caae2d26a7e36102b4770c4044101acf0712
This warning is triggered by the use of alignas() in js/public/RootingAPI.h.
Now that GeckoProfiler.h includes RootingAPI.h, this warning is encountered
when building security/certverifier because GeckoProfiler.h is already being
included transitively, through this inclusion path:
CertVerifier.cpp -> CertVerifier.h -> Telemetry.h -> StartupTimeline.h -> GeckoProfiler.h
However, this explanation is not entirely satisfactory, because there seems to
be an existing inclusion path for RootingAPI.h already:
CertVerifier.cpp -> CertVerifier.h -> BasePrincipal.h -> OriginAttributes.h
-> ChromeUtils.h -> ChromeUtilsBinding.h -> RootingAPI.h
So I'm not quite sure why this problem is only starting to happen now.
MozReview-Commit-ID: AFuXpTjdPsi
--HG--
extra : rebase_source : 60f74c8655d15fbc6acbf0ce8a2f208e198e231e
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
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
Also regenerate the test_signed_app.js testcases.
MozReview-Commit-ID: 483uNQT0wuG
--HG--
extra : rebase_source : 4dfddf89d151dceb970a1a9139a5c90e6b578f8c
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
This is the list of affected Symantec roots and the Apple and Google carved out
sub-CAs being whitelisted. These lists are created using the crtshToDNStruct
tool.
These sub-CAs are to be explicitly whitelisted in the distrust logic being
applied to Symantec root CAs.
Sources:
https://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/riCrpXsfAgAJhttps://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/90qkf8jsAQAJ
MozReview-Commit-ID: 3atUGcjG6GD
* * *
[mq]: crtsh_linting
MozReview-Commit-ID: 5gGq5DZXEIi
* * *
[mq]: fix_crtsh_script
MozReview-Commit-ID: JRgkD6OODnO
* * *
[mq]: fix_crtsh_also
MozReview-Commit-ID: Gza1HnYic2I
--HG--
extra : rebase_source : 8ca642964d3ce0308b8081fc52713d9f0104024d
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
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
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
Per the root program's request, this patch removes EV treatment for four WoSign
roots:
Common Name: CA 沃通根证书
SHA-256 Fingerprint: D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54
Common Name: Certification Authority of WoSign
SHA-256 Fingerprint: 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08
Common Name: Certification Authority of WoSign G2
SHA-256 Fingerprint: D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16
Common Name: CA WoSign ECC Root
SHA-256 Fingerprint: 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02
MozReview-Commit-ID: Bxp9LgvxCsp
--HG--
extra : rebase_source : 065d98cc654d3fb22c17ea185253ce917b48e270
Incidentally, this means we can remove certificateUsageVerifyCA and
certificateUsageStatusResponder from CertVerifier, since we no longer use them.
MozReview-Commit-ID: Bbqn8fShfTm
--HG--
extra : rebase_source : 012cb08dcbe33fe889c9f6824959b1a02cd0bdc7
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
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
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
Disable EV treatment in preparation for removing the CNNIC root certificates
from NSS.
MozReview-Commit-ID: Anz1vXqABUM
--HG--
extra : rebase_source : 694d8321b9f5994fe57e81cb3169681c5e491910
The CA, Comodo, has requested that we remove the UTN-USERFirst-Hardware
root certificate from NSS. First remove EV treatment.
MozReview-Commit-ID: 8OTsevYOuKq
--HG--
extra : rebase_source : aabb219bcbee1c667bae29df618449df4b50d548
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
GetHostNameRaw() returns a char* string, which is less safe and ergonomic
compared to the Mozilla string classes. GetHostName() can be used instead.
MozReview-Commit-ID: GYvTnISNN35
--HG--
extra : rebase_source : da257f5fba2c26cd92d932c3d1d363458b84a65b
David Keeler
J.C. Jones
Sebastian Hengst
Markus Stange
Sylvestre Ledru
Andreea Pavel
Chris Peterson
Kris Maglione
Stephanie Ouillon
Kate McKinley
Nicholas Nethercote
Cykesiopka