NSS 3.4 Release Notes
6 May 2002
Contents
- Introduction
- Distribution Information
- Bugs Fixed
- Documentation
- Changes Since NSS 3.3.2
- Platform Information
- Known Bugs and Issues
- Compatibility
- Feedback
Introduction
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.
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.
Documentation
For a list of the primary NSS documentation pages on mozilla.org, see NSS Documentation. New and revised documents available since the release of NSS 3.3 include the following:- Build Instructions for NSS 3.4.1 describe the new NSS 3.4.1 CVS tag and other minor changes since NSS 3.3.2.
- NSS 3.4 Public Functions summarizes the APIs exported by the new shared libraries. These APIs are guaranteed to work with future versions of NSS shared libraries.
- Encryption Technologies in NSS 3.4 summarizes the cryptographic algorithms implemented in NSS 3.3.
The following tools are supported in this release:
-
certutil
cmsutil
modutil
pk12util
signtool
signver
ssltap
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
- libsoftokn3.so on Unix (except HP-UX);
- libsoftokn3.sl 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- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
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 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 5.1 |
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 libbfd-2.9.5.0.22.so) |
| 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 * |
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) 9 |
Forte 6 update 2 | |
| 8 (64 bit) | 8 9 |
Forte 6 update 2 | |
| Solaris x86 | 8 | 8 9 |
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 mozilla.dev.tech.crypto.
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 ftp.cs.berkeley.edu/ucb/4bsd/README.Impt.License.Change.) 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.)
Compatibility
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.
Feedback
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 irc.mozilla.org.