Transport Layer Security, or TLS, is a cryptographic protocol for establishing encrypted communication between a client and server. NSP supports TLSv1.2 protocol by default. While not recommended, administrators can still enable TLSv.1.1 and/or TLSv1.0 in NFM-P on certain external interfaces, such as OSS clients. Upgrading legacy clients to support TLSv1.2 is preferable to enabling TLSv.1.1 and/or TLSv1.0 in NFM-P.

Note: The ability to enable unsecure protocols in NSP will be removed with little notice in a future release.

Note: Outdated TLS versions present a security risk and are disabled by default in NSP. Customers that enable older unsecure TLS protocols do so at their own risk. TLSv1.2 is the recommended version.

Cipher suites define a set of cryptographic algorithms for each TLS connection.  During cipher suite negotiation, both server and client must agree on the same cipher suite in order to establish a connection. A cipher suite defines the combination of key exchange, authentication, encryption, and integrity algorithms for the TLS connection.

• Key exchange (asymmetric cipher): Ex. ECDHE, DHE, RSA

• Authentication (signature/certificate type): Ex. RSA, DSA, ECDSA

• Confidentiality (symmetric cipher): Ex. AES_256_CBC, AES_256_GCM

• Integrity (hash): Ex. SHA384, SHA256, SHA

The following example displays the format of a TLS cipher suite.

Figure 4-1: TLS cipher suite example

NSP supports strong TLSv1.2 cipher suites by default. The default list of supported cipher suites may be updated in future releases to account for changes in the security level of cryptographic algorithms.

Perfect Forward Secrecy (PFS) is a feature of certain key agreement protocols in which there is no link between the server’s private key and each session key. Therefore, if an attacker gains access to a server private key, the attacker cannot use the private key to decrypt any archived TLS sessions. Cipher suites prefixed with "TLS_DHE" and "TLS_ECDHE" support PFS.

Note:  Exercise caution when removing TLS cipher suites; incompatible cipher suites prevent NSP system access from browser and OSS clients.

In general, TLSv1.2 ciphers compute a mac over the plaintext then the authenticated payload is encrypted.  Although highly unlikely in an NSP environment, this "mac-then-encrypt" approach could open the possibility for some sophisticated padding attacks. Authenticated Encryption with Additional Data (AEAD) is a special class of ciphers that combines encryption and integrity into one operation (ie. mac-and-encrypt). These ciphers compute mac and encrypt simultaneously which can mitigate padding attacks. In NSP, AEAD cipher suites are supported with TLSv1.2. These cipher suites are identified with Galois Counter Mode algorithms (ie. AES-GCM) and CHACHA20_POLY1305.

For cipher suites using EC based DHE key exchange, NSP supports standard TLS curves.

For cipher suites using non-EC based DHE key exchange, NSP supports 2048-bit DH parameters. Clients that do not support 2048-bit DH modulus cannot connect to NSP with a DHE cipher.

NSP clusters do not offer any cipher suites supporting DHE key exchange.

Certain attacks on TLS server's can be mitigated by enforcing the server's cipher order instead of allowing the client to choose the cipher. NSP server interfaces accessible by external TLS clients are configured to enforce server-side cipher order.

NFM-P supports the ability for administrators to customize the list of supported TLS cipher suites. The default list of cipher suites provides a balance of algorithm strength and compatibility. That said, NFM-P administrators may still chose to customize the list of supported cipher suites. See the NSP System Administrator Guide for more information about updating TLS versions and ciphers.

Note: Exercise caution when customizing TLS protocols/cipher suites. Incompatible cipher suites will prevent NSP/NFM-P system access from browser and OSS clients.

NSP supports the following three types of certificates:

• Kubernetes infrastructure certificates - Created by the Kubernetes platform and applied to the Kubernetes registry, NSP Deployer, and NSP cluster control plane.

• NSP issuer certificates - Used for signing leaf certificates that are distributed to internal NSP subsystem endpoints and external-facing NSP application endpoints. If you don’t provide an Issuer key/certificate during secrets installation, then NSP will create them for you.

• NSP server certificate - Used by NSP cluster gateway for external-facing NSP application endpoints. Also known as custom certificates. If you don't provide an NSP server key/certificate during secrets installation, NSP will use the External Issuer to sign a certificate used to secure External-facing NSP application endpoints.

NSP currently supports 2048-bit or 4096-bit RSA certificates.

Note: Certificates with RSA key size of 4096-bits are recommended.

NSP PKI server

The NSP PKI server is a standalone utility that signs TLS certificate signing requests (CSRs) from requesting entities in an NSP system. The NSP PKI server utility is mandatory and is used sign TLS certificates for internal services used by NSP components that reside outside of the cluster (such as NFM-P, or the NSP Auxiliary Database). The service uses an access control list based on the NSP cluster configuration. Consequently, the service responds only to certificate requests from known addresses in the nsp-config.yml file of the local cluster.

Note: The PKI server utility is intended for NSP components only.

Certificates signed by the NSP PKI server have the following characteristics:  

• Signature Algorithm: sha256WithRSAEncryption

• RSA key length: 2048-bit

• Validity period: configurable at NSP PKI initialization

• Organization Name: configurable at NSP PKI initialization

• Country Name: configurable at NSP PKI initialization

• State or Province Name: configurable at NSP PKI initialization

During NSP deployment, a CSR is sent to a local PKI server, which returns a signed certificate. NSP uses a server certificate and key to ‘seed’ a local copy of the PKI utility, which is active long enough to sign the pod certificates.

Note: The PKI server is intended for use by NSP components only.

Certificate Expiry

NSP TLS certificate replacement may be required when:

• a component is added to the NSP system

• a system IP/hostname changes

• a TLS certificate nears or reaches expiry

An NSP/NFM-P checks the expiry date of each local TLS certificate during installation, and every 24 hours thereafter. If a certificate is expired or approaching expiry, NSP raises one of the following SSLKeystore or SSLClientKeystore alarms:

• Warning, if the certificate is to expire within 30 days of the current time

• Critical, if the certificate is to expire within 7 days of the current time

• Critical, if the certificate is expired

NFM-P expiry alarms are shown in NSP and the Alarm Window of the NFM-P GUI.

Configuring advance warning for certificate expiry

Administrators must carefully monitor and refresh NSP TLS certificates before expiry. If certificates expire, some NSP functions that depend on secure communication may be inoperable. For example, NSP clients may be completely unable to connect to NSP.

Using the NSP and NFM-P GUI, administrators can configure alarm policies (referred to in NSP as “e-mail policies” and the NFM-P as “alarm e-mail policies”) to ensure that advance warning emails are sent for certificate expiry events. For example, an NSP policy containing an advanced filter for “Alarm Name equals SSLKeystoreCertificateExpiring” sends an email to the recipient list when NSP raises the initial warning alarm for TLS certificate expiry.

See the NSP Network and Service Assurance Guide or NSP System Administrator Guide for more information about configuring alarm e-mail policies, depending on platform installation type.