Securing your data with TLS encryption on PubSub+ broker

You can now subscribe to get notified of my latest posts!

In the last few years, it has been more important than ever to make sure your systems are sufficiently secured, especially your data. Several high profile system/data breaches have convinced corporations in different industries to treat their data with caution because those who failed to do so ended up paying a hefty price, both in terms of money and reputation.

As you might know, event brokers are the backbone of your systems as they help your data flow from one system to another. Similarly, Solace’s PubSub+ broker allows users to stream events from one application to another application across different environments in a secure and efficient manner with high throughput and low latency. While you can stream these events in plain text, it’s recommended that you protect your data by encrypting your events. Securing your data, in transit, becomes extremely important when you are streaming events across environments such as from on-prem to public cloud via Solace’s powerful Event Mesh feature.

Solace’s PubSub+ broker comes packed with numerous ways to secure your data such as restricting environment access, client/server authentication and powerful access control lists (ACLs). In this post, I will be focusing on how you can protect your data by enabling TLS encryption using server-side authentication in PubSub+ broker.

---

What is TLS?

Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), is a very popular cryptographic protocol designed to provide high-level security over computer networks. A very common usecase of TLS is securing all communication between browsers and web servers.

How does TLS work?

While I am not going to go in too much detail of mechanics of TLS, it is important to understand how it works at a high level.

There are some key components that you need to be aware of to understand TLS:

• public and private key – these are part of a key pair that can be generated by anyone. Public key can be widely distributed whereas private key must be held secret. Anything encrypted using a particular public key can only be decrypted using the corresponding private key.
• certificate – an entity containing interested party’s public key signed by a certificate authority.
• certificate authority (CA) – a well-known authority that can sign certificates using their private keys and hence guarantee the identity of a party. There are popular CAs that most browsers identify. Third parties can use CA’s public key to confirm that the certificate was signed by that CA and hence, can be trusted.

Authentication

Before data can be encrypted and shared, we need to establish identities so the two parties know they can trust each other. You have client-side authentication and server-side authentication. In this post, we will focus only on the server-side authentication. The client will authenticate itself using Basic Authentication with username and password. PubSub+ broker does support client-side authentication through client certificates.

When a TLS connection is established, a process called TLS handshake takes place. Here is a simplified version of what happens during a TLS handshake:

1. Client establishes a connection with the server and sends a ‘hello’ message with the necessary information which includes cryptographic information such as TLS version and the supported CipherSuites.
2. Server acknowledges the message and replies with its signed certificate and some additional information. If we have client-side authentication via certificate enabled, the server sends a request for client’s certificate.
3. The client receives the certificate provided by the server and uses CA’s public key to decrypt it. If the client is able to successfully decrypt it using CA’s public key, it means that the certificate was signed using the correct private key which only CA has. Because the certificate was signed by a well-known authority, we can trust that they have done the due diligence and the server is a trusted party.
4. The Client uses server’s public key to encrypt necessary information required to generate a shared key which can be used to encrypt and decrypt messages. Note that this is a simplified explanation of what actually happens.
5. If the server had requested client’s certificate, the client encrypts its certificate and private key and sends it to the server to authenticate itself.
6. The client sends a final message indicating that it has authenticated the server.
7. Finally, the server acknowledges that it has also authenticated the client and is good to go.

You can learn more about server-side authentication in PubSub+ on Solace’s docs.

Once a secured connection has been established, encrypted messages can be exchanged between the client and the server.

Configuring TLS sessions in PubSub+

PubSub+ (software) supports TLSv1.1 and TLSv1.2, currently. You can find more information about which versions are supported here. In our case, the two parties will be application and PubSub+ event broker. However, as mentioned previously, we will only focus on server-side authentication.

Generating our public/private keys

To be able to configure a TLS session, we will need to create our public/private keys as well as a self-signed certificate. The server certificate must be an x509v3 certificate and include a private key. The server certificate and key use RSA algorithm for private key generation, encryption and decryption, and they both must be encoded with a Privacy Enhanced Mail (PEM) format.

We will be using the opensource library – openssl. Let’s first generate our private key by running this command:

himanshugupta:.ssh hgupta$ openssl genpkey -algorithm RSA -aes-256-cbc -outform PEM -out private_key.pem -pkeyopt rsa_keygen_bits:2048
........+++++
.........................................................................+++++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

After you run this command, you will be asked to enter PEM pass phrase and then verify it. You will need this phrase later so make sure you remember it!

You should now have your private key:

himanshugupta:.ssh hgupta$ ls
private_key.pem

We can now use this private key to generate our public key which can be shared with others. When you run the command to generate the public key, you will be asked to provide the PEM phrase you entered earlier.

himanshugupta:.ssh hgupta$ ssh-keygen -e -f private_key.pem > public_key.pem
Enter passphrase:

himanshugupta:.ssh hgupta$ ls
private_key.pem  public_key.pem

Generating self-signed certificate

Now that we have both of our keys, next step is to create a self-signed certificate. We will first need to run the following command to issue a Certificate Signing Request (CSR).

himanshugupta:.ssh hgupta$ openssl req -new -key private_key.pem -out certificate.csr
Enter pass phrase for private_key.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:NY
Locality Name (eg, city) []:Manhattan
Organization Name (eg, company) [Internet Widgits Pty Ltd]:A Bit Deployed
Organizational Unit Name (eg, section) []:NA
Common Name (e.g. server FQDN or YOUR name) []:ABD
Email Address []:abd@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <enter_something_here>
An optional company name []: <I_left_this_blank>

himanshugupta:.ssh hgupta$ ls
certificate.csr  private_key.pem  public_key.pem

You will be asked to enter additional information such as country, state, company name etc.

Once you have your CSR, you can use it to generate a self-signed certificate by running this command:

himanshugupta:.ssh hgupta$ openssl x509 -req -days 3650 -in certificate.csr -signkey private_key.pem -out certificate.crt
Signature ok
subject=C = US, ST = NY, L = Manhattan, O = A Bit Deployed, OU = NA, CN = ABD, emailAddress = abd@example.com
Getting Private key
Enter pass phrase for private_key.pem:

himanshugupta:.ssh hgupta$ ls
certificate.crt  certificate.csr  private_key.pem  public_key.pem

It will prompt you for your PEM pass phrase and once provided, it will generate the certificate for you.

Great, we now have a self-signed certificate which we can upload to our PubSub+ broker!

Uploading self-signed certificate to PubSub+ broker

Before we do anything with PubSub+ broker, we need to make sure that the TLS port is exposed. I am using Solace’s docker container on my MacOS for this example. You can setup your own container by following instructions from this page. In the docker-compose template, make sure you comment out this line:

      #SMF over TLS
      - '55443:55443'

After you have started your docker container, you should be able to see port 55443 exposed:

himanshugupta:.ssh hgupta$ docker ps
CONTAINER ID        IMAGE                                  COMMAND               CREATED             STATUS              PORTS                                                                                                                                                                                                                                                                                                                                                        NAMES
7193ba1a990a        solace/solace-pubsub-standard:latest   "/usr/sbin/boot.sh"   2 minutes ago       Up 2 minutes        0.0.0.0:1883->1883/tcp, 0.0.0.0:5671-5672->5671-5672/tcp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:8443->8443/tcp, 0.0.0.0:8883->8883/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:9443->9443/tcp, 0.0.0.0:55003->55003/tcp, 0.0.0.0:55443->55443/tcp, 0.0.0.0:55555->55555/tcp, 0.0.0.0:1080->80/tcp, 0.0.0.0:1443->443/tcp, 0.0.0.0:1943->943/tcp   ps1

There are multiple ways to upload files to PubSub+ broker depending on how you have it installed. Because I am running it as a docker container, I am going to use the docker cp command to copy my certificate to the /certs directory in my PubSub+ docker container.

The broker needs both the certificate and private key in one file. We can do that by running this command:

himanshugupta:.ssh hgupta$ cat certificate.crt private_key.pem > certificate.pem

Now, we need to upload certificate.pem to the broker.

To do that, we need to get docker container id, which is 7193ba1a990a in my case.

We can now run the following command to upload our certificate:

himanshugupta:.ssh hgupta$ docker cp certificate.pem 7193ba1a990a:/usr/sw/jail/certs

Note, the certificate directory is /usr/sw/jail/certs in the docker container but /certs in the Solace CLI.

We can use the Solace CLI to confirm that the certificate was copied successfully:

himanshugupta:.ssh hgupta$ solace-cli

Solace PubSub+ Standard Version 9.4.0.96

The Solace PubSub+ Standard is proprietary software of
Solace Corporation. By accessing the Solace PubSub+ Standard
you are agreeing to the license terms and conditions located at
http://www.solace.com/license-software

Copyright 2004-2020 Solace Corporation. All rights reserved.

To purchase product support, please contact Solace at:
https://solace.com/contact-us/

Operating Mode: Message Routing Node

7193ba1a990a> cd certs
7193ba1a990a> dir
-rw-r--r--      503       20     3168 Apr 17 15:56 certificate.pem

We can also check to see whether the broker properly identifies the certificate:

7193ba1a990a> show ssl certificate-files
Flags Legend:
C: Certificate (Y=yes, N=no)
K: Private Key (Y=yes, N=no)

                                                 Contents
Filename                                              C K
------------------------------------------------ --------
certificate.pem                                       Y Y

We can see here that the broker is acknowledging that certificate.pem has both the certificate (C) and private key (K).

We can now set this certificate to be used for encrypted sessions by running the following command:

7193ba1a990a> home
7193ba1a990a> enable
7193ba1a990a# configure
7193ba1a990a(configure)# ssl server-certificate certificate.pem
Enter private key pass phrase:

You will be asked again to enter your PEM pass phrase from earlier.

We can confirm that our certificate is now being used:

7193ba1a990a(configure)# show ssl server-certificate
Filename:             certificate.pem
Configured at:        Apr 17 2020 16:24:16 UTC

Now, to test that we are able to establish an encrypted session, we can use Solace’s sample publisher app sdkperf_java.sh which you can download from here:

bash sdkperf_java.sh -cip=tcps://localhost:55443 -stl=t/a/1 -cn=encrypted

From the Solace CLI, we can see the connection details for our client encrypted000001:

7193ba1a990a# show client encrypted000001 detail

Primary Virtual Router:

Client:                       encrypted000001
Type:                         Primary
Client Profile:               default
ACL Profile:                  default
Authorization Group:
------
------
SSL Version:                  TLSv1.2
SSL Cipher:                   ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA
                                Enc=AES(256) Mac=SHA384
SSL Downgraded to Plain Text: No

This confirms that our connection is using TLSv1.2 and is encrypted!

As we saw, encryption is extremely important to secure our data from anyone looking to manipulate or steal our data. With Solace’s PubSub+ broker, it is very easy to encrypt your data in transit with TLS.