Adapted from https://wiki.mozilla.org/SecurityEngineering/NSS_Startup_and_Shutdown_in_Gecko :
Properly implementing the coordinated shutdown of NSS has, to date, proved
intractable. For architectural reasons and due to the significant complexity
involved, the NSS resource tracking and shutdown infrastructure has been an
ongoing source of crashes and hangs in Firefox. To that end, we have been
exploring the possibility of not shutting down NSS at all. For this to work, we
have had to address a number of potential concerns.
Certificate and key database corruption: In theory, if Firefox were to exit
without coordinating with NSS, data stored in the certificate and key databases
(backed by BerkeleyDB) could be lost. To mitigate this, we have migrated to
using the sqlite-backed implementation. The databases are now journaled, and
short of a bug in sqlite, we do not anticipate data loss due to database
corruption.
PKCS#11 devices: In theory, if Firefox were to exit without coordinating with
NSS and thus any attached PKCS#11 devices, data could be lost on these devices.
However, it is our understanding that these devices must be robust against
unexpected physical removal. Uncoordinated shutdown should present no worse a
risk to user data.
FIPS 140-2 mode: While Mozilla does not ship a version of Firefox that supports
FIPS mode out of the box, Red Hat does. It is our understanding that clearing
key material is a requirement of FIPS and that not shutting down NSS may pose a
problem for this requirement. Red Hat's FIPS 140-2 Security Policy[0] specifies
that the application (i.e. Firefox) using the module (i.e. NSS) is responsible
for zeroization of key material. More specifically, it says "All plaintext
secret and private keys must be zeroized when the Module is shut down (with a
FC_Finalize call), reinitialized (with a FC_InitToken call), or when the session
is closed (with a FC_CloseSession or FC_CloseAllSessions call)." Thus, if
Firefox never shuts down NSS, this requirement is trivially met.
Leak detection: By not shutting down NSS, technically we leak some allocated
memory until shutdown. This could cause problems if our test infrastructure
detected and reported these leaks. However, it appears not to (which itself is
somewhat concerning). In any case, we will have to deal with this if and when we
can detect these leaks.
Given that these concerns all have at least a preliminary answer, we will move
forward with attempting to not shut down NSS in Firefox. This may expose
unexpected issues that may lead to a reassessment of the situation, so this will
be on a trial basis only in Nightly.
[0] https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3070.pdf
MozReview-Commit-ID: LjgEl1UZqkC
--HG--
extra : rebase_source : 99bf715f7f6566ec92ca763eefdbd8d2f69d2ba2
extra : amend_source : d4177cc87f54fccbd49312feef7e29b77bf01432
As of bug 1257362, the platform does not verify code signing certificates in
general, so anything involving the code signing trust of certificates can go.
MozReview-Commit-ID: 9g9kM62xfYZ
--HG--
extra : rebase_source : 5bec64e5f451c8433aff0de82a91f7bd54c24608
