[I cannot participate in any legal discussions now. Please don't ask
me questions about legal stuff.]
We (Mozilla) are are exploring some approaches to statically link NSS
into Firefox to reduce dynamic linkage overhead caused by the NSS shared
libraries and to allow for whole-program optimization (and dead code
removal) for NSS based on Firefox performance profiles. I am interested
in what others think of this approach and what approach other client
software developers are planning to take. I am also interested in
knowing how I can help get reviews of the necessary patches in a short
time frame. I am not an NSS reviewer but I can at least pre-review
patches to save other reviewers time (as I did for the TLS 1.1/1.2
patches) and I could give such reviews much higher priority if others
respond in kind.
Changing the way that NSS (Softoken and FreeBL, in particular) is linked
into Firefox means changing the strategy for FIPS 140 compliance of the
browser, and FIPS 140 compliance is an important concern. But, the vast
majority of our users--and all of our mobile users--run in normal
(non-FIPS) mode and we need to optimize for that case so that people pay
(performance-wise) for FIPS mode only when they enable FIPS mode--even
if that would mean that the FIPS mode would have more overhead than it
has now. The approach outlined below is very similar in spirit to the
bypass mode added to NSS to improve the performance of Sun's NSS-based
products. Basically, we just want NSS to be optimized for clients like
Firefox as much as it is optimized for the server products that use it,
like Nelson mentioned during our lunch meeting. I think this approach
will cause minimal disruption to other products using NSS while still
allowing us to make necessary performance improvements and size
reductions in Firefox.
1. Create a supported configuration of NSPR+NSS (in the NSS CVS trunk)
that that supports static linking with profile-guided optimization (PGO)
and whole-program optimization (WPO). Wan-Teh has already written
patches to do this for Chrome and those patches have been tweaked by
others at Mozilla. But, we need reviewers for the patches after they are
cleaned up. See [1] and [2].
2. Update the NSS source code (primarily in libssl, Softoken, and
FreeBL) to allow us to exclude dead code sections from the build when
the the compiler's WPO cannot remove them automatically (e.g. libssl's
server-side code code when linked into Firefox, the bypass mode code,
and anything in FreeBL/Softoken that isn't actually used by Firefox).
3. Decouple the release of the FIPS-validated Softoken from the release
of the browser. For example, if we need to ship a version of Firefox
that needs some crypto bits that are in a version of Softoken/FreeBL
that hasn't yet been validated, then we will ship the release with the
newer NSS and provide the FIPS-validated version afterwards. Put another
way, FIPS mode issues won't block Firefox. (Because of Firefox Sync, we
are now always going to have crypto features that won't work in FIPS mode.)
4. Provide a "FIPS mode" option in Firefox wherein the statically-linked
Softoken and FreeBL are disabled in favor of the use of a
dynamically-loaded FIPS-validated PKCS#11 module. If Softoken is the
FIPS-validated module, then NSPR and NSS must support being loaded
multiple times into the same process (once statically linked, and at
least once dynamically linked).
5. Add the few missing bits to FreeBL that would be needed to have a
100% bypass mode (no PKCS#11 usage) in the client part of libssl, and
then remove most/all of the statically-linked copy of Softoken from
Firefox in favor of using the FreeBL interface directly. We would still
support the non-bypass mode specifically for FIPS mode. I have done some
experiments with this and it seems like it doesn't require much
additional code added to FreeBL; I can probably eliminate as much code
as I add.
6. Remove the FIPS-validated Softoken from the default Firefox
distribution, and distribute it as part of an add-on.
7. Use operating-system APIs for client authentication, so that client
certificates and smart cards are stored and managed by the operating
system's APIs and tools. I know there is a PKCS#11 interface to native
OS interfaces in NSS already, but I think we can provide a better
experience for users by just using the native APIs--and probably do so
with little maintenance cost (in NSS) and notably less overhead. Note
that this means we will never support client authentication with static
ECDH/DH encryption keys; we will only support key exchange mechanisms
where the client has to provide a signature.
8. On platforms where we use the system NSS shared libraries, allow a
configuration where the system NSS libraries are used for client
cert/smartcard support while the built-in static NSS is used for
everything else.
Cheers,
Brian
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=534471
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=561842
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
