An illustrated TLS connection: learn about each step in detail

Get to know through an illustrated TLS how private data is protected

The wise saying says that the rope always breaks at its weakest point. That is why today we will cover the subject of safe communications with an illustrated TLS connection.

In a previous article, we talked about the Caddy Web Server, which incorporates the Transfer Layer Security or TLS (its accronym) by default, which provides us very important security for our communications with our Pandora FMS server, our banks, social networks, etc.

Once upon a time…

As the beginning of children’s stories says, we will tell you a bit of history: the popularization of encrypted communications (which can be intercepted by third parties but whose content would take a long time to decipher, which means our personal data) arose as a result of the scandals related to the information leakage of the hacker Edward Snowden. At this point you may realize that this article is appropriate not only for us geeks, since the case had a huge media coverage worldwide and surely you have heard about it. Thanks to this incident, most browsers today warn whether a page is not encrypted and even deny the connection if the security certificate is self-signed.
In order to massify our privacy, the Electronic Frontier Foundation, better known as EFF, created the program Let’s Encrypt so that with just one little donation a year you can count on certificates automatically and massively in your blogs, company websites, etc. In fact, Caddy Web Server includes Let’s Encrypt installed by default!
Then, HTTPS is available to everyone. Indeed, that famous lock icon that appears on our web browser, usually in green or blue (depending on the certifying authority), which originally came to be by merging HTTP and SSL (“Secure Sockets Layer“) which today is completely “obsolete” and has been replaced by TLS in order to make it impregnable.

Pandora FMS and its console

At this point, we must make clear that Pandora FMS (along with a huge number of web applications) uses a web server for console operations and its Application Program Interface (API), and it is our duty to acquire a security certificate to install it and guarantee privacy when monitoring systems. But all of what we are explaining here is beyond the scope of the Pandora FMS source code.

In case you are wondering: “In what (safe) way does Pandora FMS communicate with its software agents?”. The answer is the Tentacle protocol and here you have a guide for your own certifications with OpenSSL. After this general overview, let us get into the illustrated TLS.

Coffee

We recommend it since you will need it to get your neurons ready for this journey. Seriously.

Illustrated TLS

In November 2018, Mr. Michael Driscoll created the illustrated TLS version 1.3, under the software license of Massachusetts Institute of Technology (MIT license), so that understanding how this technology works, step by step, byte by byte, would be easier (which he managed to portray very well). In this link you can see live how the 1.3 version and also the previous 1.2 version work. Here we will describe the latest version and the process of sending the word “ping” encrypted (with an encrypted answer too: “pong”) in a very summarized way.

Terms used

Just a few necessary concepts:

• Endpoint: one of the two ends in communication, the client or the server.
• Client: the endpoint that initiates communication.
• Connection: the transport layer that communicates both endpoints.
• Handshake; here we will place greeting: the negotiation between both endpoints in order to agree which protocols to use.
• Private key: a very, very special number that we can either generate ourselves or can be provided by a trustworthy certifying entity. In both cases, a corresponding public key will be calculated by complex mathematical devices, which will be the one we will give to everyone with whom we are going to communicate.

Client key generation

Prior to connecting, the client randomly selects a very large number to use as private key and with a mathematical formula (in this example X25519, proposed by Daniel J. Bernstein) proceeds to generate a public key that will be the one that will provide safe communication to anybody (with OpenSSL you will be able to confirm its mathematical relation).

Client greeting (connection start)

The client sends a packet introducing itself with the information about the TLS to be used. Do you remember that we mentioned SSL? Well, the client sends the “31” keyword in hexadecimal to tell the server that it is able to understand TLS 1.0 (SSL 3 + TLS 1 = “31”) But weren’t we talking about TLS 1.3 ? Yes, but for backward compatibility it is necessary to indicate to the server that your client manages all these versions:

• TLS 1.0: “31”.
• TLS 1.1: “32”.
• TLS 1.2: “33”.
• TLS 1.3: “34”.

Also, for compatibility reasons we send a non-empty session identifier, although it is not necessary in TLS1.3 since it uses PSK (pre-shared keys). Another important value is SNI (Server Name Indication) for web servers that host multiple web domains together. The new features are encryption methods, narrowed down to the safest ones in TLS1.3, as well as not using compression.

Server key generation

Once the greeting is received, the server performs the same job done by the client before answering.

Server greeting (response to connection)

If the server supports TLS1.3 here, it will still send a “32” (TLS1.2), probably the same session identifier that the client sent (which we will not actually use) accompanied by the very important server public key calculated at that point. Among other values, it will send the encryption method, in this case AES128 and SHA256. Notice that we have not started encrypting any communication yet; all this can be intercepted and read by a third party without much effort, but let us continue.

Calculation of keys in both parts

It is worth clarifying that, although encrypted, the packets will be “tagged” (first 5 bytes) as TLS1.2 for all of those which are in the middle, since the norm is very recent it can lead to these intermediaries blocking our messages. This happens because Internet is a series of interconnected computers and they trace a “path” between us and our destiny.

Conclusion of the greeting

• The server will send its granted security certificate, provided by Let’sEncrypt for example. What is this? Well, basically, it is the public key generated from the private key generated by Let’sEncrypt, in addition to the identifiers for this certifying entity. The interesting thing about this process is that these identifiers are also certificates backed by other certifying entities in a trust chain that will eventually reach a pre-installed security certificate in the web browser of the client.
• The server takes the public key from the client and combines it with its own private key and the client does the same too. It is here where all encrypted communication starts, which is what really differentiates TLS1.3. However, packages with superfluous information will be exchanged by backward compatibility.
• In addition, the server will mathematically bind the public key generated for this connection with its own private key that belongs to its security certificate granted by Let’sEncrypt (go for it, we are about to finish).
• Although there are other processes that we will not mention, the next important step is that both server and client will make a digital trace or hash made with an SHA256 algorithm for all these messages in TLS1.3 format (without the 5-byte header that identifies them as TLS1.2 publicly to avoid blocking) that have been exchanged. This is done in order to verify throughout the conversation that ALL encrypted packets that are sent and received are issued by who they claim to be.

Simplified process: the conversation

The greeting and encryption process is much simpler than what it seems. Here we illustrate it as a conversation between client and server:

Client: Hello! I would like to establish a secure communication between us, over here I hand you out my encrypted code and the SSL/TLS suitable version.
“Server key generation” and “Server greeting (response to connection)”
Server: Hello! How are you dear client? I have already checked the encrypted code and the SSL/TLS version. They are ok, so let’s continue with the conversation. I send you my certificate and my public key. Check them out!
“Calculation of keys in both parts”
Client: Let me check them… hum… yes, they seem correct, but first I need to verify your private key. To do this, do the following: generate and encrypt a pre-master (a shared secret key) using your public key. Next, decrypt it using your private key and use the master key to encrypt and decrypt the information. Is that ok with you?
Server: Perfect!
“Conclusion of the greeting”

Now that both client and server have made sure who they are really talking to (after checking the certificate Let’s Encrypt), the information they exchange will be safely transferred.

Sending the “ping”

The client will be able to send the word “ping” in an encrypted form, the server will also answer “pong” in an encrypted form, but in addition, it will send us two session identifiers before (with additional security measures). Those usually expire in 48 hours, to accelerate the following connections and not repeat completely all this process that we have just analyzed. Brilliant, right?

You already have in your web browser the session identifiers needed for you to read our other articles. ¿Do you still want to know more about IT system monitoring? Luckily, you are at the right place to find out more. In this blog, there are dozens of articles that can get you in this exciting world. Here is a link to our home page: https://pandorafms.com/blog/en/

Or you can also contact Pandora FMS directly if you have more than 100 devices to monitor. Just click here: https://pandorafms.com/contact/

If you have a reduced number of machines to monitor, you can learn more about the Pandora FMS OpenSource version here:
https://pandorafms.org