Summary:
Change the security.pki.name_matching_mode pref to 3 for Enforce on Nightly.
BR_9_2_1_SUBJECT_ALT_NAMES show that ~99.98% of encountered certificates have
an acceptable SAN, so our compatibility risk is about 0.02%.
BR_9_2_2_SUBJECT_COMMON_NAME also shows, 99.89% of certificate common names are
present in a subject alternative name extension, giving a worst-case of 0.11%
risk, though BR_9_2_1_SUBJECT_ALT_NAMES is more what we're affecting here.
Test Plan: none
Reviewers: keeler
Tags: #secure-revision
Bug #: 1461373
Differential Revision: https://phabricator.services.mozilla.com/D1277
--HG--
extra : transplant_source : %BF%7D%DEi%C7%9BhE%D0%C2d%9D0%AC%F8%9EM%E0%60U
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
If a user has set a master password on their NSS DB(s), when we try to change
the trust of a certificate, we may have to authenticate to the DB. This involves
bringing up a dialog box, executing javascript, spinning the event loop, etc.
In some cases (particularly when antivirus software has injected code into
Firefox), this can cause the nsNSSComponent to be initialized if it hasn't
already been. So, it's a really, really bad idea to attempt to change the trust
of a certificate while we're initializing nsNSSComponent, because this results
in a recursive component dependency and everything breaks. To get around this,
if we need to load 3rd party roots (e.g. enterprise roots or the family safety
root), we defer any trust changes to a later event loop tick. In theory this
could cause verification failures early in startup. We'll have to see if this
is an issue in practice.
MozReview-Commit-ID: FvjHP5dTmpP
--HG--
extra : rebase_source : 73d39788ce39adcbe01c89867061f64d05a3876b
If a user has set a master password on their NSS DB(s), when we try to change
the trust of a certificate, we may have to authenticate to the DB. This involves
bringing up a dialog box, executing javascript, spinning the event loop, etc.
In some cases (particularly when antivirus software has injected code into
Firefox), this can cause the nsNSSComponent to be initialized if it hasn't
already been. So, it's a really, really bad idea to attempt to change the trust
of a certificate while we're initializing nsNSSComponent, because this results
in a recursive component dependency and everything breaks. To get around this,
if we need to load 3rd party roots (e.g. enterprise roots or the family safety
root), we defer any trust changes to a later event loop tick. In theory this
could cause verification failures early in startup. We'll have to see if this
is an issue in practice.
MozReview-Commit-ID: FvjHP5dTmpP
--HG--
extra : rebase_source : ad0fb83a0de3632e3a967e91aec3d8070b22dedc
Summary:
No bug, Automated HPKP preload list update from task XSqPd8faStCdsylVmzvQ6w
No bug, Automated blocklist update from task XSqPd8faStCdsylVmzvQ6w
Reviewers: sfraser, aki
Reviewed By: sfraser
Differential Revision: https://phabricator.services.mozilla.com/D1256
--HG--
extra : rebase_source : 855e19990c75e2613bd311976297fb6513e02b94
Bug 1456489 cleaned up our OCSP request implementation a bit. One simplification
it made was to not cancel the timeout timer. It turns out that if we don't, the
OCSPRequest that constitutes the timeout callback's closure might not be valid
if the request has completed (because the timer doesn't own a strong reference
to it). The fix is simple: cancel the timer when the request completes. Note
that we don't have to do the reverse because necko has a strong reference to the
request.
MozReview-Commit-ID: 2WHFLAcGBAw
--HG--
extra : rebase_source : c4216f6792c1d62cbd046b1b3802226c51fbe8af
(Backed out changeset 6bbf8dc0b86e (which was a backout of changeset 0a5795108e0a))
MozReview-Commit-ID: EZFn7dLBcdh
--HG--
extra : rebase_source : 8fac1e33a7f108a248ecde35779b2c63ce7d9172
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
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 1372694 added a firefox-appdir line to PSM's xpcshell.ini. It turns out this
breaks running these tests locally because utilities like BadCertServer can't be
found. I looks like the change isn't necessary, so the simplest thing to do
would be to just remove the addition.
MozReview-Commit-ID: 8fg8ujPWxRe
--HG--
extra : rebase_source : ffef9b067dacb94c4bd554f97556ab95f58efd2b
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Update Mac sandbox rules to allow executable mappings from /Library/GPUBundles which is
used by the Nvidia downloadable "Web" driver.
MozReview-Commit-ID: L2nTP4YWdJJ
--HG--
extra : rebase_source : d8eefdd5a180db5d3ea8207d923e021420f2318e
(This also fixes Bug 879740 and Bug 1204543.)
build/pgo/certs contains an NSS database set that has a bunch of hand-generated
certificates, and many of these hand-generated certificates are specifically
depended upon for a variety of unit tests. This patch changes all of these to
use the "pycert.py" and "pykey.py" utilities that produce deterministic keys
and certificates.
The naming convention here is new, and defined in the README. It is based on
the mochitest runtest.py naming convention that imports .ca and .client
PEM-encoded certificates.
Unfortunately, the updates to build/pgo/genpgocert.py to generate these files
depends on OpenSSL in order to produce PKCS12 archives for pk11tool to import
into NSS. This could be done with pure-NSS tooling, but it'd require some new
command line functionality, which is out-of-scope for this change.
Note that build/pgo/genpgocert.py no longer takes arguments when run. It's not
run automatically anywhere that I can see, but could (reasonably) be, now.
Differential Revision: https://phabricator.services.mozilla.com/D971
--HG--
extra : amend_source : bc389b9b0a807a4889feb14db439daa28635dfe9
This patch uses the shared memory name prefixes introduced in bug 1447867
to prevent access to /dev/shm files of other applications or other
processes within the same browser instance.
When a shared memory implementation that doesn't use shm_open is available
(specifically, the memfd_create support to be added in bug 1440203),
/dev/shm access is completely denied.
MozReview-Commit-ID: L2ylG5KrXTU
--HG--
extra : rebase_source : ca1deece6117e843d691a13fff05bd0f97ec0408
These functions cause main-thread certificate verifications, which is bad for
performance. In general, nsIX509CertDB.asyncVerifyCertAtTime should be used
instead.
MozReview-Commit-ID: 9nkUDmyFY0k
--HG--
extra : rebase_source : d3e8a02e2d21e5507e71681b88f0360edf64b790
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
