You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

NSS 3.4 Release Notes

6 May 2002




Network Security Services (NSS) 3.4 is a minor release with the following new features:
  • A new function SSL_GetChannelInfo() that returns more information on an SSL channel than the SSL_SecurityStatus() function.
  • A new multi-process SSL server session cache implemented in shared memory.
  • AES ciphersuites for TLS.
  • PKCS #11 library database format.
In addition, NSS 3.4 contains a partial implementation of the core NSS 4.0 functions.  These new NSS 4.0 functions are not exposed but rather the current NSS functions are emulated on top of them.
NSS 3.4 is dual-licensed under the MPL and the GPL.

Distribution Information

The CVS tag for the NSS 3.4 release is NSS_3_4_RTM.  It has been certified with both NSPR 4.1.2 and NSPR 4.2.

At the time of this writing, NSS 3.4.1 has been released, therefore we do not provide the source tarball and binary distributions of NSS 3.4 on our ftp site.  Please refer to the NSS 3.4.1 release notes for the NSS 3.4.1 distribution information.

Bugs Fixed

For a list of all bugs that have been fixed in the NSS 3.4 release, click here.


For a list of the primary NSS documentation pages on, see NSS Documentation. New and revised documents available since the release of NSS 3.3 include the following: Source may be viewed with a browser (via the LXR tool) at

The following tools are supported in this release:

For documentation and other information about these tools, see NSS Tools.

Changes Since NSS 3.3.2

For a list of changes introduced in NSS 3.3.2, see NSS 3.3.2 Release Notes.

The sections that follow discuss specific changes since NSS 3.3.2 in more detail.

New NSS shared library

In previous NSS releases, the softoken was part of the NSS base shared library (nss3).  In NSS 3.4, the softoken becomes a separate shared library (softokn3) that the NSS base shared library depends on.

The softoken shared library does not export any functions that NSS clients call directly. Therefore, on most platforms NSS clients don't need to link with the softoken shared library explicitly. They only need to link with the NSS base shared library (nss3) as before and the runtime loader will load the softoken shared library (an implicity dependency of nss3) automatically. Special linker options may be required on some platforms. For example, on Linux the -rpath-link option for ld needs to be used.

The name of the softoken shared library is
  • on Unix (except HP-UX);
  • on HP-UX;
  • softokn3.dll on Windows.

Obsolete NSS header files

The following NSS header files are not exported in NSS 3.4.
  • keydbt.h, keylow.h, keytboth.h, and keytlow.h: No NSS clients should depend on the contents of these header files.  In NSS 3.4, the contents of these header files are only used by the softoken, so there is no point to export these headers, not even for other parts of NSS.
  • nssckp.h and nsscku.h: The nssck*.h headers that used to include these two headers are now simply including the corresponding pkcs11*.h headers, which are using pkcs11p.h and pkcs11u.h. So these two headers have been removed.
  • secrngt.h: This header was empty.

New NSS header files

NSS 3.4 has three new exported header files. In general NSS clients do not need to include these new headers directly.
  • nssilckt.h: This file was split out from nssilock.h. nssilock.h includes nssilckt.h.
  • pkcs11n.h: This file was split out from pkcs11t.h for the NSS extensions to Cryptoki. pkcs11t.h includes pkcs11n.h.
  • sslt.h: This file was split out from ssl.h. ssl.h includes sslt.h.

New NSS public functions

The new public functions exported by NSS 3.4 are described here.
  • SSL_GetChannelInfo(): returns assorted security state information about the SSL connection, including the ciphersuite negotiated and information about the keys used. This function is intended to supersede SSL_SecurityStatus().
  • SSL_GetCipherSuiteInfo(): returns detailed information about the specified SSL/TLS ciphersuite.
  • SSL_LocalCertificate(): returns a reference (that is, a reference-counted pointer) to the CERTCertificate structure for the leaf certificate that was sent to the peer during the last full handshake with the peer on this SSL socket.  To avoid leaks, the caller of this function should destroy the reference by calling CERT_DestroyCertificate() when it is done with the reference.
  • SSL_GetMaxServerCacheLocks() and SSL_SetMaxServerCacheLocks(): these functions allow an SSL server to tune the number of locks used in the SSL server session cache.  Note that the implementation of these locks is system dependent.  On some systems, these locks are scarce resources.  The SSL_SetMaxServerCacheLocks() function is only useful prior to the call that initializes the SSL server session cache, for example, SSL_ConfigServerSessionIDCache() or SSL_ConfigMPServerSIDCache().

New SSL Server Session Cache

The SSL server session cache has been reimplemented to use shared memory.  It is no longer necessary for a server to allocate a number of SSL server session cache entries that is many times bigger than the number of SSL sessions anticipated in a 24-hour period.

New AES TLS ciphersuites supported

In NSS 3.4, the ciphersuites known formally as
are now supported. To ensure that older programs do not use these new cipher suites inadvertently, these new cipher suites are NOT enabled by default. Note that the DHE ciphersuites work only on the client side (there is no server-side implementation yet). Therefore, server products should not enable the DHE ciphersuites.

To use these new cipher suites, an application must enable them explicitly by a call to SSL_CipherPrefSetDefault or SSL_CipherPrefSet. The new cipher suites are properly handled by the policy functions NSS_SetDomesticPolicy, NSS_SetExportPolicy, and NSS_SetFrancePolicy. Applications that call SSL_CipherPolicySet instead of one of these three policy functions must also call SSL_CipherPolicySet for these new cipher suites if they wish to use these new cipher suites.

Platform Information

NSS is maintained on the platforms listed in the table. "Build" means the NSS team has built NSS on a machine with the specified OS. "Certified" means the NSS team has run QA tests for NSS on a machine with the specified OS.

Platform Build Certify Compiler(s)
AIX 4.3.3 (32 bit) 4.3.3
xlC/C++ 3.6.6
4.3.3 (64 bit) 4.3.3 xlC/C++ 3.6.6
Compaq Tru64 5.0A 5.0A 
Compaq C V6.1-019
HP-UX 11.0 (32 bit) 11.0 C compiler: A.11.01.00
11.0 (64 bit) 11.0 C compiler A.11.01.00
Linux 2.2 Red Hat 6.0 Red Hat 6.2 egcs-1.1.2
GNU ld version 2.9.5 (with
Linux 2.4 Red Hat 7.1 Red Hat 7.1 gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
NT NT 4.0 w/ SP 6a NT 4.0 w/ SP 6a 
Win2000 w/ SP 2
VC++ 6.0 Service Pack 4
Windows NT 4.0 w/ SP 6a NT 4.0 w/ SP 6a 
Win2000 w/ SP 2

Win95 OSR2 * 
Win98 SE * 
Win Me *

VC++ 6.0 Service Pack 4
Solaris SPARC 2.6 2.6 WorkShop Compilers 
C/C++ version 5.0
8 (32 bit) 8 (32 bit)
8 (64 bit)
Forte 6 update 2
8 (64 bit) 8
Forte 6 update 2
Solaris x86 8 8
Forte 6 update 2
Mac OS 9 8.5 * 
8.6 * 
9 *
Metrowerks CodeWarrior Pro 5

* Full QA certification will not be done on these platforms. We will only verify that PSM built with NSS 3.3 works on these platforms.

** Optional.

NSS has not yet been formally tested or certified on any other platforms. If you have successfully run NSS on other platforms, or if you are interested in taking responsibility for testing and maintaining NSS on a particular platform that's not listed above, post a message to

Note about Windows NT builds: The build listed in the left column above as the "Windows NT" build runs on Windows NT (including Windows 2000) only and hence can potentially take advantage of some Win32 functions that are only implemented on Windows NT, such as fibers and I/O completion ports. The build listed above as the "Windows" build runs on all Windows flavors -- 95, 98, Me, NT, and 2000.

Only NSPR makes use of this Windows NT vs. Windows distinction and provides different Windows NT and Windows builds. Many Netscape products, including NSS, have Windows NT and Windows builds that are essentially the same except one difference: one is linked with the Windows NT version of NSPR and the other is linked with the Windows version of NSPR.

Note to Macintosh Developers: Due to a lack of resources, our team was unable to build and test NSS for the Macintosh platform. We are looking for help from any interested parties to test NSS 3.3 on Macintosh. For contact information, please see the Feedback section.

Known Bugs and Issues

1. NSS 3.4 uses mozilla/dbm, which is based on Berkeley DB 1.85. Berkeley DB 1.85 is released under the original BSD license, whose "advertising clause" is incompatible with the GNU GPL.

In a letter dated July 22, 1999, UC Berkeley announced that the advertising clause is deleted from all the BSD Unix files (of any version of BSD) containing the clause. (The announcement is available at The final (AT&T proprietary) 4.4BSD release contained version 1.6 of Berkeley DB. The 4.4BSD-Lite2 release contained version 1.74 of Berkeley DB. Since Berkeley DB 1.85 is not technically in any version of BSD (although it is derived from the Berkeley DB files in 4.4BSD and 4.4BSD-Lite2), it is not clear whether the Berkeley announcement means that the advertising clause has been deleted from Berkeley DB 1.85.

2. For a list of reported bugs that have not been fixed in NSS 3.4, click here. (Note that not all of these bugs have been confirmed. Even some bugs in the "new" state are unconfirmed.)


NSS 3.4 shared libraries are backward compatible with NSS 3.2.x and NSS 3.3.x shared libraries. A program linked with NSS 3.2.x or 3.3.x shared libraries will work with NSS 3.4 shared libraries without recompiling or relinking.  Furthermore, applications that restrict their use of NSS APIs to the functions listed in NSS 3.4 Public Functions will remain compatible with future versions of the NSS shared libraries.


Bugs discovered should be reported by filing a bug report with bugzilla (product NSS).

You can also give feedback directly to the developers on the IRC channel #mozcrypto on the server