(mozilla-projects-nss-nss-3-35-release-notes)=

# NSS 3.35 release notes

## [Introduction](#introduction)

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

## [Distribution Information](#distribution_information)

:::{container}
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:

- Source tarballs:
  <https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_35_RTM/src/>
:::

(new-in-nss-3-35)=

## [New in NSS 3.35](#new_in_nss_3.35)

### [New Functionality](#new_functionality)

:::{container}

- 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.

```{rubric} 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. Note that this release does not include support for the latter.
:::

(notable-changes-in-nss-3-35)=

## [Notable Changes in NSS 3.35](#notable_changes_in_nss_3.35)

:::{container}

- 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.db 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 which 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 partial, and
    migration of keys from DBM to SQL will be delayed, until this master password is provided
    to NSS. (Conversely, NSS will never synchronize data from SQL to 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 should not be used for production purposes.

- NSS 3.30 had introduced a regression, preventing NSS from reading some AES encrypted data,
  produced by older versions of NSS. NSS 3.35 fixes this 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 from 1024-bit
      roots per [Bug #1045189](https://bugzilla.mozilla.org/show_bug.cgi?id=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:

  - Support for KeyUpdate was added. KeyUpdate will be used automatically, if a cipher is used
    for a sufficient number of records.
  - 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 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 promoted in draft -23, but this is currently not compliant with the
    DTLS 1.3 draft -23 specification.

- 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.)

- 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 this does not affect
  ABI compatibility, because PRBool is a typedef for PRIntn.
:::

(experimental-apis-and-functionality)=

## [Experimental APIs and Functionality](#experimental_apis_and_functionality)

:::{container}
The functionality and the APIs listed in this section are experimental. Any of these APIs may be
removed from future NSS versions. Applications *must not* rely on these APIs to be present. If an
application is linked at runtime to a later version of NSS, which no longer provides any of these
APIs, the application *must* handle the scenario gracefully.

In order to ease transitions, experimental functions return SECFailure and set the
SSL_ERROR_UNSUPPORTED_EXPERIMENTAL_API code if the selected API is not available. Experimental
functions will always return this result if they are disabled or removed from a later NSS
release. If these experimental functions are made permanent in a later NSS release, no change to
code is necessary.

(Only APIs exported in \*.def files are stable APIs.)
:::

(new-experimental-functionality-provided)=

### [New experimental functionality provided](#new_experimental_functionality_provided)

:::{container}
Below are descriptions of experimental functionality, which might not be available in future
releases of NSS.

- 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:

  - 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.
  - An anti-replay mechanism was added for 0-RTT, through the experimental SSL_SetupAntiReplay
    function. *This mechanism must be enabled for 0-RTT to be accepted when NSS is being used
    as a server.*
  - KeyUpdate can be triggered by the experimental SSL_KeyUpdate() function.
  - 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, which 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.
:::

(new-experimental-apis)=

### [New experimental APIs](#new_experimental_apis)

:::{container}
Below is a list of experimental functions, which might not be available in future releases of
NSS.

- *in sslexp.h*

  - *experimental:* **SSL_KeyUpdate** - prompt NSS to update traffic keys (TLS 1.3 only).
  - *experimental:* **SSL_GetExtensionSupport** - query NSS support for a TLS extension.
  - *experimental:* **SSL_InstallExtensionHooks** - install custom handlers for a TLS
    extension.
  - *experimental:* **SSL_SetupAntiReplay** - configure a TLS server for 0-RTT anti-replay (TLS
    1.3 server only).
  - *experimental:* **SSL_SendSessionTicket** - send a session ticket (TLS 1.3 server only).
:::

(removed-experimental-apis)=

### [Removed experimental APIs](#removed_experimental_apis)

:::{container}
Note that experimental APIs might get removed from NSS without announcing removals in the release
notes. This section might be incomplete.

- The experimental API SSL_UseAltServerHelloType has been disabled.
:::

(bugs-fixed-in-nss-3-35)=

## [Bugs fixed in NSS 3.35](#bugs_fixed_in_nss_3.35)

:::{container}
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>
:::

## [Compatibility](#compatibility)

:::{container}
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](#feedback)

:::{container}
Bugs discovered should be reported by filing a bug report with
[bugzilla.mozilla.org](https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS) (select product
'NSS').
:::
