Encrypting Data in Motion between Splunk (Enterprise & UF) and Cribl Stream
A series of 4 blogs about Encrypting data in motion between Splunk and Cribl
Have you had any problems when using TLS to safeguard data in transit?
Have you ever been unsure —
which certificate should go where…
how to specify that setting…
I’m making it easy to learn and use in this blog series.
Let’s break things down first, and then the detailed stepwise procedure is discussed step by step in different parts of this blog series.
First, let’s understand a few fundamental concepts —
Transport layer Security (TLS) is a protocol that encrypts data sent over the network to prevent hackers from seeing your data.
TLS provides end-to-end security of data sent between devices, along with providing encryption, authentication, and integrity.
The two communicating devices agree on a secret key that only they know to communicate.
TLS uses Symmetric or Secret key cryptography which means the data is encrypted and decrypted with the same secret key (hence, called symmetric) known to both the sender and receiver.
TLS only encrypts the data over the network (data in motion) and not in the device (data at rest).
The purpose of TLS is —
- privacy, — by encrypting the data between endpoints — to ensure even if anyone intercepts this data, he/she will only see a garbled mix of characters that is nearly impossible to decrypt.
- authentication (the web server and/or the client) — by the handshake between endpoints — to ensure that both devices are really who they claim to be.
- data integrity — by digital signing — to ensure data is not tampered with before reaching its intended recipient.
The below diagram explains how TLS can be broken down
Its previous version is known as SSL (Secure Socket Layer). SSL has not been updated since SSL 3.0 in 1996 and is now considered to be deprecated. There are several known vulnerabilities in the SSL protocol so most modern web browsers no longer support SSL. However, the term SSL is still used interchangeably with TLS to denote TLS.
In the year 1999, the first version of TLS was proposed by the Internet Engineering Task Force (IETF), an international standards organization.
Over a period, the TLS protocol has gone through several version updates to improve speed and enhance security.
The current and most secure version of TLS is version 1.3 which was released in 2018.
Mutual TLS, or mTLS for short, is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification.
Part 2 — Acquiring the necessary CA signed certs and associated passphrases — Read Part 2 here
In the enterprise environment, it will be acquired by internal admins as they might have already procured on wildcard cert which can be utilized for various subdomains/applications published on one enterprise domain.
I attempted to generate the Domain name and TLS Certs/key from a free provider to discuss it in this blog series without incurring any costs. The link above explains how it was created.
Part 3— Securing the Cribl Destination log stream toward the Splunk indexer —Read Part 3 here
In this blog article, we will discuss how to configure the public CA-signed TLS Certs/key for encrypting data in transit “from the Cribl host” as log source/client “to Splunk indexer” destination/server.
Part 4— Securing the Cribl source log stream from Splunk UF/HF — Read Part 4 here
In this blog article, we will discuss how to configure the public CA-signed TLS Certs/key for encrypting data in transit “from the Splunk UF/HF” host as log source/client “to the Cribl host” as destination/server.
P.S. — I recently came across the blog from Cribl on the same topic which is also a good reference for high level information.
Your comments and suggestions are welcomed.
