PSM:MozAppsWithSharedNSSDB
Introduction
Planning document for the NSS shared database feature in all Mozilla applications. The work is to be done in module PSM (core code).
Firefox et. al. use NSS for crypto operations (SSL etc.). Each Mozilla application profile directory contains several NSS database files which contain personal certificates, the key to encrypt remembered passwords, trust information for certificate authorities, information about installed external crypto hardware (e.g. smartcards), etc.
As of today, all the above must be managed for each application and profile separately. It's desirable to share this information across multiple applications and profiles. By default, this storage shall be user specific across all NSS based applications. This page is about the required changes to Mozilla/PSM in order to make this sharing happen.
Status
The shared database feature is considered a stable feature of the NSS library. It's already possible to make use of profile sharing using environment variables. More information can be found on the corresponding NSS wiki pages:
The feature shall get enabled for Mozilla applications by default (without requiring environment variables) in future Firefox and Thunderbird versions.
Migration
Future application versions shall access the user's shared database by default.
The first time a sharing application is started it shall automatically migrate (merge) the old information (from the profile directory) to the new location (the shared database).
The code to perform a migration has already been implemented as part of the NSS library, however, the merge operation must be initiated by the application and may require user interaction.
In a simple scenario, the new shared database does not yet exist. The first time the new sharing application is started the new shared database will automatically get created with the same content and (potentially) master password as the old database.
In a worst case scenario, the sharing application gets started for the first time, is protected with a master password, the shared database has already been created and is protected by a master password, too, and both passwords are different.
In this latter scenario it's necessary to prompt the user about the necessary merge operation and prompt for both the old and the new master passwords.
Discussion: Multi profile migration
The proposal is to use the user's default shared database whenever no special requests have been made by the user (no environment variable points to a secondary shared database).
Question: Is this default behavior safe for all common scenarios?
Let's consider a user account who owns multiple Firefox profiles.
Let's consider a home computer where several family members share a computer, and for simplicity there is no user account separation. However, each family member uses their own separate Firefox profile.
In this scenario the private keys, personal certificates and CA Certificate trust from all individual profiles would get migrated to the common shared database.
Is this merge-all-profiles approach a good idea?
Or does this scenario propose that we shall implement multiple separate shared databases, based on the application's profile name? For example, should Firefox profiles named "default" and a Thunderbird profile shared "default" both use the same database, but profiles named "father" and "mother" should use their own separate shared databases?
Implementation decisions to be made
On Linux, Mac OSX and other unix platforms: $HOME/.nssdb/
(However, on some SuSE Linux systems the shared database feature has already been enabled for applications, and the default path used is: $HOME/.local/var/pki/nssdb/ )
On Windows: %APPDATA%\NSS\
On Mac OSX: $HOME/Library/Application Support/NSS/
Disadvantage of using a default path
Usually the path to Mozilla profile files contain a random component, a salt. For example, on Linux systems the path is ~/.mozilla/firefox/xxxxxxxx.default/ where xxxxxxxx is a random value.
The use of the salt makes it harder for malicious web sites to use potential application exploits to steal a user's files, because the salt is unknown to the attacker.
When switching to a user specific default path that shall work with any NSS based application, it seems necessary to stop using a salt component.
As a consequence the path to a user's default certificate database files will be known.
A secondary database may be stored in any directory a user desires. They SHOULD NOT be subdirectories of the default path.
Optional: How to request the use of a secondary database
Despite the advantages of having a global NSS database, an advanced user might deliberately want to use a different database, e.g. when performing tests or when acting with a different identity.
Proposal:
By default, all Mozilla applications shall use the user-wide NSS default database.
An advanced user who desires to use a different secondary database shall set an environment variable to override the default behavior.
Proposal: Use environment variable NSS_SHARED_DB_PATH
(This proposal is derived from SuSE Linux who already has introduced this variable.)
Recording of db path information in profiles
Should there be a link from application profile configuration files to a shared database location? For example, a three step approach could be used that involves both environment variable and a preference: - preference is empty by default, this means use the default path - preference is set to a database which the application will use - however if the environment variable is set, it will override the profile preference
NSS documents
While this page focuses on the Mozilla application point of view, several documents have already been written that have more details about the NSS shared database feature:
