TLS/SSL Message Encryption

By default, clients use plain text over TCP to exchange data with Solace PubSub+ message brokers, and the data that is exchanged is not compressed.

However, clients can use Transport Layer Security (TLS)/ Secure Sockets Layer (SSL)‑encrypted connections to a message broker. This allows an exchange of uncompressed Solace Message Format (SMF) data or Solace Element Management Protocol (SEMP) data with the message broker using TLS/SSL over single TCP connections instead of plain text over TCP.

Using TLS/SSL-encrypted connections to a message broker offers:

  • confidentiality—messages can only be received by the intended recipient
  • message integrity—messages cannot be modified after being sent
  • server authentication—the connected application is able to verify the server it is communicating with is the server it believes it is
  • client authentication—optional client certificates can be used as a form of client authentication (for more information, refer to Client Authentication/Authorization)

The following types of applications can establish TLS/SSL-encrypted connections to a message broker:

  • Client applications that publish and/or receive messages.
  • By default, when a client application connects to a message broker and creates a session, that session is unsecured. However, a client application can optionally create a secure session that requires a trusted server certificate to establish a TLS/SSL-encrypted client connection to a message broker.

    Client applications can use the Solace messaging APIs to establish secure connections to a message broker.

  • Network management applications that manage and monitor the message broker through SEMP requests and replies.
    • If the network management application uses SEMP Request Over Message Bus service, which uses a Solace messaging API to establish a client connection through a session, SEMP requests and replies can be sent over the message broker message bus. A secure session can be established in the same manner as that used by a client application.
    • If the network management application uses SEMP Request over HTTP service, a TCP connection to a port on the message broker allows the application to send SEMP requests wrapped in HTTP to a management interface on the message broker and receive replies to them. For SEMP Request over HTTP service, a secure connection can be created when a server certificate is set on the message broker, a TLS/SSL-secure port is specified (443 by default), and an HTTPS URL scheme is used.

SSL encryption can also be used on Message VPN bridges and bridges established by the Message VPN replication and replication Config-Sync facilities. Using encryption on bridge links helps to ensure that communications between message brokers over bridges are secure.

Note:  Because encrypting and decrypting data requires processing power, enabling TLS/SSL encryption may cause a reduction in performance.

Cipher Suites

The following cryptographic algorithms are used throughout the life of a TLS/SSL‑encrypted connection:

  1. Key establishment—This algorithm is used to exchange or agree on the symmetric keys to be used for encrypting and decrypting the data payload during the session. Examples: RSA, Diffie-Hellman (DH), Ephemeral Diffie-Hellman (DHE), and Elliptic Curve Diffie-Hellman (ECDH).
  2. Authentication—This algorithm is the digital signature used by the certificates passed between the client application and server. Examples: RSA and Digital Signature Standard (DSS).
  3. Encryption—This algorithm encrypts and decrypts payload passed on the secure session. Examples: RC4, 3DES CBC, and Advanced Encryption Standard (AES).
  4. Digest—This algorithm is used to maintain message integrity. Tampering with the message would render the digest invalid. Examples: SHA1, MD5.

The combination of these four cryptographic algorithms is known as a cipher suite.

For the full list of cipher suites message brokers support, refer to Supported Cipher Suites.

Cipher Suites for Inbound Connections

Message brokers maintain a separate cipher suite list for each of the following inbound TLS connection types:

  • Network management applications using SEMP to manage the message broker (management connections)
  • Client applications connecting to the message broker to publish or receive messages (message backbone connections)

Cipher suites for all inbound management and message backbone connections are selected according to the priority clients associate with each cipher suite.

Cipher Suites for Outbound Connections

Message brokers maintain a separate prioritized cipher suite list for each of the following outbound TLS connection types:

  • Message VPN and bridge connections
  • Replication bridge connections
  • Config-sync bridge connections
  • Multi-node routing links

In addition, the message broker uses the same cipher suite list for outbound LDAP connections that it uses for inbound management connections.

Cipher suites for all outbound connections (including LDAP connections) are selected according to the priority configured in each corresponding cipher suite list.

Ciphers for SSH Connections

Message brokers maintain a list of ciphers for all SSH, SCP, and SFTP connections. For purposes of encrypted connections, the cipher list has a similar function to a cipher suite list; however, key establishment, authentication, and digest algorithms are not used. For the full list of ciphers message brokers support, refer to Supported Ciphers.

Ciphers for all SSH connections are selected according to the priority clients associate with each cipher.

Supported Cipher Suites

The following table shows the full list of cipher suites message brokers support for inbound and outbound connections.

Supported Cipher Suites

Cipher Suites
(strongest to weakest)

Key Establishment

Authentication

Encryption

Digest

ECDHE-RSA-AES256-GCM-SHA384

ECDH

RSA

AES GCM (256)

SHA2

ECDHE-RSA-AES256-SHA384

ECDH

RSA

AES CBC (256)

SHA2

ECDHE-RSA-AES256-SHA

ECDH

RSA

AES CBC (256)

SHA1

AES256-GCM-SHA384

RSA

RSA

AES GCM (256)

SHA2

AES256-SHA256

RSA

RSA

AES CBC (256)

SHA2

AES256-SHA

RSA

RSA

AES CBC (256)

SHA1

ECDHE-RSA-DES-CB3-SHA

ECDH

RSA

3DES CBC (168)

SHA1

DES-CBC3-SHA

RSA

RSA

3DES CBC (168)

SHA1

ECDHE-RSA-AES128-GCM-SHA256

ECDH

RSA

AES GCM (128)

SHA2

ECDHE-RSA-AES128-SHA256

ECDH

RSA

AES CBC (128)

SHA2

ECDHE-RSA-AES128-SHA

ECDH

RSA

AES CBC (128)

SHA1

AES128-GCM-SHA256

RSA

RSA

AES GCM (128)

SHA2

AES128-SHA256

RSA

RSA

AES CBC (128)

SHA2

AES128-SHA

RSA

RSA

AES CBC (128)

SHA1

Note:  When using TLS 1.2, certificate keys must be at least 1024 bits in length. When using keys shorter than 1024 bits, you may receive a “digest too big for RSA key” error.

Supported Ciphers

The following table shows the full list of ciphers message brokers support for SSH connections.

Supported Ciphers

Ciphers
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
aes128-cbc
3des-cbc
blowfish-cbc
cast128-cbc
aes192-cbc
aes256-cbc

Configuring Cipher and Cipher Suite Lists

You can configure each default cipher and cipher suite list to avoid using specified ciphers or cipher suites, or you can reorder each list to change the priority associated with a given cipher or cipher suite.

To configure cipher suite lists for inbound connections, refer to Configuring Cipher Suites for Inbound Connections.

To configure cipher suite lists for outbound connections, refer to the following sections:

To configure ciphers for SSH connections, refer to Configuring Ciphers for SSH Connections.

Supported Signature Algorithms

A message broker can validate a certificate chain if all certificates in the chain are signed with one of the following signature algorithms:

Supported Signature Algorithms

Signature Algorithm

md2withRSAEncryption

md4withRSAEncryption

md5withRSAEncryption

shawithRSAEncryption

sha1withRSAEncryption

sha1withDSAEncryption

sha224withRSAEncryption

sha224withDSAEncryption

sha256withRSAEncryption

sha256withDSAEncryption

sha384withRSAEncryption

sha512withRSAEncryption

Server Certificates Authentication Process

The following process is used when a client or management application connects to a message broker and requires certificate validation to establish a secure connection.

Certificate Validation Process Using TLS/SSL

  1. The client or management application connects to the message broker’s TLS/SSL listening port.
  2. The message broker responds to the client or management application with its server certificate.
  3. If an Active/Active redundancy configuration is used, each message broker in the redundant pair should have its own server certificate with its own common name. If an Active/Standby redundancy configuration is used, the two mates can share a server certificate that uses the name of the primary message broker as the common name.

  4. The client or management application verifies that the server certificate is valid, is named as expected, and that it was issued by a trusted root certificate.
  5. If the validation succeeds, the client or management application will respond and continue to complete the handshake.

Certificate Authorities

A message broker allows clients to authenticate over TLS by presenting a valid client certificate issued by a Certificate Authority (CA). Each participating message broker must be configured with a list of CAs to be trusted so that the client's certificate obtained during the security protocol exchanges can be verified. The process of configuring each CA in the client certificate chain as a trusted root certificate is required for authentication and is a mandatory step in trusting a CA. A message broker can also be configured to use a CA with certificate revocation checking.

Certificate Revocation Checking

Checking the revocation status of client certificates is supported for Solace PubSub+ appliances as of Version 8.2.0, and is supported by the Solace PubSub+ software message brokers as of version 8.7.0. Before these releases, while validating the client certificates, the message broker did not check the revocation status of the certificates.

A message broker can check the revocation status of the certificate that clients use when attempting to authenticate. The certificate revocation is configurable on a per-message broker basis with override options per-Message VPN. You can configure Message VPN overrides to ignore the results of the revocation check or to allow authentication of certificates with unknown revocation status. For more information, see Configuring Message VPN Overrides.

The revocation status of a certificate chain can have one of the following states:

  • Valid—All certificates in the chain have been checked for revocation and for whether they are valid.
  • Unknown—One or more certificate in the chain cannot be verified. It is, however, possible for OCSP to return unknown if the certificate is not revoked and not known to the CA.
  • Revoked—One or more certificate in the chain have been revoked.

With the certificate revocation checking enabled, there are several potential conditions that may lead to the status of a certificate chain to be unknown. The information below describe those conditions when CRL, OCSP, or OCSP-CRL certificate revocation check is enabled:

  • CRL—If a cached copy of the CRL is not available or if the CRL has expired.

  • OCSP—If the message broker does not receive a response from the OCSP responder within the default timeout, or if the response signer is not recognized as a genuine responder. The responder is required to sign the OCSP responder with certificates issued to specific common names and must contain appropriate OCSP flags.

  • OCSP-CRL—When using OCSP-CRL, following conditions may lead to the revocation status of a certificate to be unknown:

    • The OCSP response signer is not recognized as a genuine responder.

    • The message broker does not receive a response from the OCSP responder within the default timeout and a cached copy of the CRL is not available, or if the CRL has expired.

To learn about CRL, OCSP, OCSP-CRL certficate revocation checking, see Certificate Revocation Checking Methods

Clients that Support Certificate Revocation Checking

The table below shows the list of clients that support certificate revocation checking.

Clients that Support Certificate Revocation Checking

Authentication Source Certificate Revocation Checking Supported
SMF client Yes
MQTT client Yes
REST publisher Yes
REST subscriber No
MQTT client Yes
Web Messaging client Yes

For information on certificate revocation configurations, see Certificate Authorities.

Certificate Revocation Checking Methods

You can configure message brokers to check the revocation status of client certificates using Certificate Revocation List (CRL), Online Certificate Status Protocol (OCSP), or OCSP-CRL (a combination of both the methods).

CRL

CRL contains a list of certificates that have been revoked by the issuing CA. The URL to the CAs certificate revocation list is embedded in each certificate. The message broker downloads the CRL from the distribution point and keeps a local copy that it refreshes periodically. To authenticate client certificates, the verifying application uses the CRL URL to download a local copy of the CRL, which it then uses for every revocation check that CA needs to make. The revocation status of all the certificates in the chain and its issuing CA is checked—starting from the last issued certificate—to the root CA itself. If the serial numbers of the certificates do not appear in the CRL, then the certificates pass the revocation check.

Note:  During CRL revocation check, the root CA gets two counts because it is checking itself once and checking the CA below in the chain once. All the other CAs get one count because they are only checking the one below them or, in the case of the last CA in the chain, it's checking the client that tried to connect.

To enable CRL certificate revocation checking, see Configuring CRL Certificate Revocation Checking.

OCSP

OCSP allows a message broker to check the revocation status of a single certificate directly with the CA or through a trusted responder (OCSP responder) inside the firewall. The client certificate contains a URL of the issuer of the certificate, which is used to check the revocation status of the certificate. With the OCSP method, each certificate in the chain is verified by sending a request with the certificate’s serial number to an OCSP responder. The responder must reply to indicate if the certificate has been revoked or whether it is valid or unknown.

To enable OCSP certificate revocation checking, see Configuring OCSP Certificate Revocation Checking.

OCSP-CRL

When both the OCSP and CRL certificate revocation checking are used, the revocation status of all the certificates in the chain will be first checked by OCSP. If the result is valid, unknown or revoked, the check is complete. If the OCSP responder returns unknown (response timeout) or unavailable, then the certificate will be checked by the CRL. This process is performed on each certificate in the chain.

To enable OCSP-CRL certificate revocation checking, see Configuring OCSP-CRL Certificate Revocation Checking.