Transport Security and Compression

By default, the clients use single TCP connections instead of plain text over TCP to exchange data with Solace routers, and the data that is exchanged is not compressed.

However, clients can also establish Transport Layer Security (TLS)/ Secure Sockets Layer (SSL)‑encrypted connections to a Solace router so that they can exchange uncompressed Solace Message Format (SMF) data or Solace Element Management Protocol (SEMP) data with the Solace router using TLS/SSL over single TCP connections instead of plain text over TCP.

Using TLS/SSL-encrypted connections to a router 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 follow types of applications can establish TLS/SSL-encrypted connections to a Solace router:

  • Client applications that publish and/or receive messages.
  • By default, when a client application connects to a Solace router 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 Solace router.

    Client applications can use the Solace messaging APIs for Java, Java RTO, C, .NET, or JMS to establish secure connections to a Solace router.

  • Network management applications that manage and monitor the Solace router 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 router 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 router allows the application to send SEMP requests wrapped in HTTP to a management interface on the router 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 router, 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 Solace routers over bridges are secure.

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

Supported 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 that passed on 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.

Supported Cipher Suites

OpenSSL Cipher Suite
(strongest to weakest)

Key Establish.

Authent.

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.
  • The following GCM cipher suites are not supported by Java and are thus not supported in the JMS and Java Messaging APIs:
    • ECDHE-RSA-AES256-GCM-SHA384
    • AES256-GCM-SHA384
    • ECDHE-RSA-AES128-GCM-SHA256
    • AES128-GCM-SHA256

Supported Signature Algorithms

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

  • md2withRSAEncryption
  • md4withRSAEncryption
  • md5withRSAEncryption
  • shawithRSAEncryption
  • sha1withRSAEncryption
  • sha1withDSAEncryption
  • sha224withRSAEncryption
  • sha224withDSAEncryption
  • sha256withRSAEncryption
  • sha256withDSAEncryption
  • sha384withRSAEncryption
  • sha512withRSAEncryption

Process of Authenticating Server Certificates

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

Certificate Validation Process Using TLS/SSL

  1. The client or management application connects to the router’s TLS/SSL listening port.
  2. The router responds to the client or management application with its server certificate.
  3. If an Active/Active redundancy configuration is used, each router 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 router 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.

Message Compression

An application using the Solace enterprise or OpenMAMA messaging APIs can enable the compression of message data sent between it and the Solace Messaging Platform so that message data is compressed before transmission and decompressed on reception.

Note:  Message compression is not supported for clients using Solace Web messaging APIs, REST, or MQTT.

Message compression reduces the size of message data frames to be transmitted over a network link. Reducing the size of a frame reduces the time required to transmit the frame across the network. Data compression provides a coding scheme at each end of a transmission link that allows characters to be removed from the frames of data at the sending side of the link and then replaced correctly at the receiving side. Because the condensed frames take up less bandwidth, greater volumes of data can be transmitted at any one time.

Using data compression may reduce bandwidth consumption and provide lower latency over low-bandwidth connections between clients and routers.

Functional Description

On Solace routers, compression and decompression of message data is performed by the Network Acceleration Blade (NAB). For clients using the messaging APIs, compression and decompression of message data is performed by the third-party library.

When channel compression is used, a Solace router listens to a special TCP port (by default, 55003). Therefore, the value for the session property on the client side must be set to match the port number on the router.

For compression on the router side, the message data is sent from the publishing client into the NAB compression engine of the Solace router for compressing. Once the compressed data is available, it is sent out to the subscribing clients over the client connection.

For decompression on the router side, the Solace router puts the compressed message data received from the connection into the NAB decompression engine for decompressing. Once the decompressed message data is available, it is handed over to the upper layer application for further processing.

Note:  If an unrecoverable error is detected during decompression operation, the associated connection is disconnected. This applies to both the router and client API ends of the transmission link.