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
This patch also switches all GlobalSign EV roots to using the CA/Browser Forum
EV policy OID.
Differential Revision: https://phabricator.services.mozilla.com/D8258
--HG--
extra : moz-landing-system : lando
This patch removes the remaining mozilla-specific dependencies from the
certificate transparency implementation.
Depends on D6845
Differential Revision: https://phabricator.services.mozilla.com/D6846
--HG--
extra : moz-landing-system : lando
In order to make our certificate transparency implementation standalone, we
have to remove mozilla-specific dependencies such as mozilla::Vector.
Depends on D6844
Differential Revision: https://phabricator.services.mozilla.com/D6845
--HG--
extra : moz-landing-system : lando
I also changed security/certverifier/moz.build a bit while I am here:
* Using '-Xclang' to pass through '-Wall' on clang-cl.
* Now clang-cl will take clang/gcc path because most '-wd****' options have no
effect on clang-cl. '-wd4010' will have an effect, but we already have the
corresponding clang/gcc option ('-Wno-unused-parameter').
--HG--
extra : source : df566a1bd9087cc0bfc03fe19fd9d21bf58f5d9c
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.
There is a late-breaking EV compatibility concern with cross signatures for EV
certificates:
Firefox's EV handling code always validates EV using the first EV policy OID
expressed in a certificate. For compatibility certificates issued under a cross-
signed root, if the first EV policy OID matches the original Symantec EV policy
OID, then Firefox will attempt to verify that the root CA matches the original
Symantec EV CA -- which it won't, as the root will be one of DigiCert's. Without
a patch, EV treatment will break.
This patch removes all EV policy OIDs for roots mentioned in TrustOverride-
SymantecData.inc, letting the moz::pkix algorithm pick other EV policy OIDs to
validate. I verified that I removed all affected OIDs using the BASH shell
commands:
$ cd security/certverifier
$ grep "CN=" TrustOverride-SymantecData.inc | sed -e 's/.*\(CN=.*\).*/\1/' |
sort | uniq | while read r; do
echo $r; grep "$r" ExtendedValidation.cpp;
done
Reviewers should help me ensure that I did not remove any unexpected EV policy
OIDs.
Differential Revision: https://phabricator.services.mozilla.com/D4709
--HG--
extra : moz-landing-system : lando
We can't use memcmp to compare PODs, largely because of undefined
padding. The rest of the Pod* functions are fine though, since we're
replicating or zeroing PODs.
MozReview-Commit-ID: LSspAi8qCWw
Defining nsINSSComponent in idl rather than manually in a header file allows us
to make full use of the machinery that already exists to process and generate
the correct definitions. Furthermore, it enables us to define JS-accessible APIs
on nsINSSComponent, which enables us to build frontend features that can work
directly with the data and functionality the underlying implementation has
access to.
MozReview-Commit-ID: JFI9s12wmRE
--HG--
extra : rebase_source : 16b660e37db681c8823cbb6b7ff59dd0d35f7e73
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
Don't use MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS; it's unneeded here right now,
and occludes "PSM::Result" on Windows.
--HG--
extra : transplant_source : %B9%24%7FR%A8%1B%B0%3B%D44%ED%C5%3F%CD%1E%96%1F%22m%A3
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 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
Nathan Froyd
Dana Keeler
Franziskus Kiefer
Mark Goodwin
Masatoshi Kimura
Ted Mielczarek
J.C. Jones
Jeff Gilbert
Xidorn Quan
Andi-Bogdan Postelnicu
Narcis Beleuzu
Miko Mynttinen
arthur.iakab
Emilio Cobos Álvarez
Sebastian Hengst
Tristan Bourvon