NSS 3.35 release notes

 

DRAFT (remove line when document is finished)

Introduction

The NSS team has released Network Security Services (NSS) 3.35, which is a minor release.

Distribution Information

The HG tag is NSS_3_35_RTM. NSS 3.35 requires NSPR 4.18 or newer.

NSS 3.35 source distributions are available on ftp.mozilla.org for secure HTTPS download:

New in NSS 3.35

New Functionality

  • TLS 1.3 support has been updated to draft -23.  This includes a large number of changes since 3.34, which supported only draft -18.  See below for details.
  • Users of TLS are now able to provide implementations of TLS extensions through an experimental custom extension API.  See the documentation in sslexp.h for SSL_InstallExtensionHooks for more information on this feature.
  • Several experimental APIs were added in support of TLS 1.3 features.

New Functions

  • in sslexp.h - note that these are experimental functions that might not be available in future releases of NSS; once these functions are stable, they will be exposed through the ABI
    • SSL_KeyUpdate - cause NSS to update traffic keys (TLS 1.3 only)
    • SSL_GetExtensionSupport - query NSS support for a given TLS extension
    • SSL_InstallExtensionHooks - install custom handlers for a TLS extension
    • SSL_SetupAntiReplay - configure a TLS server for 0-RTT anti-replay (TLS 1.3 server only)
    • SSL_SendSessionTicket - send a session ticket (TLS 1.3 server only)

New Types

  • in sslt.h
    • SSLHandshakeType - The type of a TLS handshake message.
    • For the SSLSignatureScheme enum, the enumerated values ssl_sig_rsa_pss_sha* are deprecated in response to a change in TLS 1.3.  Please use the equivalent ssl_sig_rsa_pss_rsae_sha* for rsaEncryption keys or ssl_sig_rsa_pss_pss_sha* for PSS keys (noting that this release does not include support for the latter).

New Macros

  • in ___.h
    • macro - description

Notable Changes in NSS 3.35

  • Previously, NSS used the DBM file format by default. Starting with version 3.35, NSS uses the SQL file format by default. Below are explanations that could be helpful for environments that need to adopt to the new default.
    • If NSS is initialized in read-write mode with a database directory provided, it uses database files to store certificates, key, trust and other information. NSS supports two different database file formats:
      • DBM: The legacy file format based on Berkeley DB, using filenames cert8.db, key3.db and secmod.db. Parallel database access by multiple applications is forbidden, as it will likely result in data corruption.
      • SQL: the newer file format based on SQLite, using filenames cert9.db, key4.and and pkcs11.txt. Parallel database access by multiple applications is supported.
    • Applications using NSS may explicitly request to use a specific database format, by adding a type prefix to the database directory provided at NSS initialization time. Without a prefix, the default database type will be used (DBM in versions prior to 3.35, and SQL in version 3.35 and later.)
    • When using the SQL type (either explicitly or because of the new default) with a database directory that already contains a DBM type database, NSS will automatically perform a one time migration of the information contained in the DBM files to the newer SQL files. If a master password was set on the DBM database, then the initial migration may be partially, and migration of keys from DBM to SQL will be delayed until the master password is provided to NSS. (NSS will never synchronize data from the SQL to the DBM format.)
    • Additional information can be found on this Fedora Linux project page: https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql
  • Added formally verified implementations of non-vectorized Chacha20 and non-vectorized Poly1305 64-bit
  • For stronger security, when creating encrypted PKCS#7 or PKCS#12 data, the iteration count for the password based encryption algorithm has been increased to one million iterations. Note that debug builds will use a lower count for better performance in test environments. As a reminder, debug builds shouldn't be used for production purposes.
  • NSS 3.30 had introduced a regression that prevented NSS from reading some AES encrypted data produced by older versions of NSS. NSS 3.35 fixes the regression and restores the ability to read affected data.
  • The following CA certificates were Removed:
    • OU = Security Communication EV RootCA1
      • SHA-256 Fingerprint: A2:2D:BA:68:1E:97:37:6E:2D:39:7D:72:8A:AE:3A:9B:62:96:B9:FD:BA:60:BC:2E:11:F6:47:F2:C6:75:FB:37
    • CN = CA Disig Root R1
      • SHA-256 Fingerprint: F9:6F:23:F4:C3:E7:9C:07:7A:46:98:8D:5A:F5:90:06:76:A0:F0:39:CB:64:5D:D1:75:49:B2:16:C8:24:40:CE
    • CN = DST ACES CA X6
      • SHA-256 Fingerprint: 76:7C:95:5A:76:41:2C:89:AF:68:8E:90:A1:C7:0F:55:6C:FD:6B:60:25:DB:EA:10:41:6D:7E:B6:83:1F:8C:40
    • Subject CN = VeriSign Class 3 Secure Server CA - G2
      • SHA-256 Fingerprint: 0A:41:51:D5:E5:8B:84:B8:AC:E5:3A:5C:12:12:2A:C9:59:CD:69:91:FB:B3:8E:99:B5:76:C0:AB:DA:C3:58:14
      • This intermediate cert had been directly included to help with transition off of 1024-bit roots per Bug #1045189.
  • The Websites (TLS/SSL) trust bit was turned off for the following CA certificates:
    • CN = Chambers of Commerce Root
      • SHA-256 Fingerprint: 0C:25:8A:12:A5:67:4A:EF:25:F2:8B:A7:DC:FA:EC:EE:A3:48:E5:41:E6:F5:CC:4E:E6:3B:71:B3:61:60:6A:C3
    • CN = Global Chambersign Root
      • SHA-256 Fingerprint: EF:3C:B4:17:FC:8E:BF:6F:97:87:6C:9E:4E:CE:39:DE:1E:A5:FE:64:91:41:D1:02:8B:7D:11:C0:B2:29:8C:ED
  • Significant changes to TLS 1.3 were made along with the update from draft -18 to draft -23:
    • An anti-replay mechanism was added for 0-RTT through the experimental SSL_SetupAntiReplay function.  Note that this mechanism must be enabled for 0-RTT to function when NSS is being used as a server.
    • Support for KeyUpdate was added.  KeyUpdate will be used automatically if a cipher is used for a sufficient number of records, or it can be triggered by the experimental SSL_KeyUpdate() function.
    • SSL_KEYLOGFILE support was updated for TLS 1.3.
    • An option to enable TLS 1.3 compatibility mode, SSL_ENABLE_TLS13_COMPAT_MODE, was added.
    • Note: In this release, support for the new rsa_pss_pss_shaX signature schemes have been disabled; end-entity certificates with RSA-PSS keys will still be used to produce signatures, but they will use the rsa_pss_rsae_shaX codepoints.
    • Note: The value of ssl_tls13_key_share_xtn value from the SSLExtensionType has been renumbered to match changes in TLS 1.3. This is not expected to cause problems; code compiled against previous versions of TLS will now refer to an unsupported codepoint if this value was used.  Recompilation should correct any mismatches.
    • Note: DTLS support is advertised at draft -23, but this is currently not compliant with the DTLS 1.3 draft -23 specification.
  • TLS servers are able to send session tickets to clients on demand using the experimental SSL_SendSessionTicket function.  This ticket can include arbitrary application-chosen content.
  • TLS servers are able to handle a ClientHello statelessly if the client supports TLS 1.3.  If the server sends a HelloRetryRequest, it is possible to discard the server socket and make a new socket to handle any subsequent ClientHello.  This better enables stateless server operation.  (This feature is added in support of QUIC, but it also has utility for DTLS 1.3 servers.)
    • TLS servers can screen new TLS 1.3 connections as they are made using the experimental SSL_HelloRetryRequestCallback function.  This function allows for callbacks to be installed that are called when a server receives a new TLS ClientHello.  The application is then able to examine application-chosen content from the session tickets or HelloRetryRequest cookie and decide whether to proceed with the connection.  For an initial ClientHello, an application can control whether NSS sends a HelloRetryRequest and include application-chosen content in the cookie.
  • The tstclnt utility now supports DTLS using the -P option.  Note that a DTLS server is also provided in tstclnt.
  • TLS compression is no longer possible with NSS.  The option can be enabled, but NSS will no longer negotiate compression.
  • The signatures of functions SSL_OptionSet, SSL_OptionGet, SSL_OptionSetDefault and SSL_OptionGetDefault have been modified to take a PRIntn argument rather than PRBool.  This makes it clearer that options can have values other than 0 or 1.  Note that this does not affect ABI compatibility because PRBool is a typedef for PRIntn.
  • The experimental SSL_UseAltServerHelloType API has been disabled.

Bugs fixed in NSS 3.35

This Bugzilla query returns all the bugs fixed in NSS 3.35:

https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&classification=Components&query_format=advanced&product=NSS&target_milestone=3.35

Acknowledgements

The NSS development team would like to thank ... for responsibly disclosing the issue by providing advance copies of their research.

Compatibility

NSS 3.35 shared libraries are backward compatible with all older NSS 3.x shared libraries. A program linked with older NSS 3.x shared libraries will work with NSS 3.35 shared libraries without recompiling or relinking. Furthermore, applications that restrict their use of NSS APIs to the functions listed in NSS 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.mozilla.org (product NSS).

 

 

Document Tags and Contributors

 Contributors to this page: kaie, m_t, kwilson
 Last updated by: kaie,