TLS: UNDERSTANDING POSTGRESQL’S COMMUNICATION ENCRYPTION

Preamble

What is TLS?

The term “Transport Layer Security,” or TLS, refers to a method of protecting the data you send over TCP connections from hackers.

You must first have a basic understanding of encryption in order to understand how TLS functions.

Parallel encryption

You have basic symmetric encryption if you take the text “I like cheese” and replace every character with the next one in the English alphabet (replacing a with b, b with c,… and z with a). If you send your friend the message “j mjlf diddtf,” they can read it and replace each character with the one before it (replacing b with a, c with b,… and a with z), revealing your favorite snack.

Symmetric encryptions can be described mathematically as follows:
If enc(x, k) = e is the function that encrypts x into e using key k, then the inverse function enc-1(e, k) = x is used to decrypt e back into x using k.

This is a very straightforward example that is simple to understand. Data can be encrypted symmetrically in much more complex ways that cannot be decrypted without the key. The Enigma machine, which was used in the second world war, is a well-known illustration of symmetric encryption. Even today, it is still challenging to decipher the more complex enigma (IV) encryption, even though the simpler enigma (III) encryption was decipherable for much of World War Two.

Symmetric encryption has two issues with practicality. On the one hand, you’ll need a variety of keys (basically one for each connection), which prevents client B from decrypting anything the server sends to client A, for example. On the other hand, there is no straightforward method of securely sharing the key with new clients.

Due to the high level of trust and infrequent connection changes between two servers that communicate with one another, this is not a problem. Your clients can’t be trusted to the same extent, and new ones might be added frequently (especially since you have little control over their hardware and software).

Therefore, you require something different in order for the clients to be able to send and receive encrypted messages.

Asymmetric Cryptography

Asymmetric encryption is built on the concept of a key pair, which consists of a private key and a public key. Both are typically derived from the same set of random numbers, and while the public key can be used to encrypt data, only the private key can be used to decrypt it again.

This means that anyone can encrypt messages they want to send to you using your public key, but only you can decrypt them using the private key.

Asymmetric encryptions can be described mathematically as follows:
if enc(x, k_pub)=e is the function that encrypts x, using public key k_pub, into e,
then the function dec(e, k_priv)=x is used to decrypt e, using private key k_priv, back into x.

There are asymmetric encryptions that are less secure than others, just like symmetric encryption, but we don’t need to worry about that right now.
The fact that we can send encrypted data without having to give the client access to our secret key is what matters.

Validation of Signature

Asymmetric encryption also has the advantage of being able to sign data in addition to encrypting it. To create a signature, the sender can compute the data’s checksum and encrypt it using their private key. Using the same data, the recipient computes the checksum and compares it to the sender’s checksum, which was obtained by decrypting the signature with the help of the public key.

How does TLS work?

Asymmetric and symmetric encryption are both used by TLS. Keep in mind that every connection should have a unique key for symmetric encryption, and that secure key exchange is challenging. However, symmetric encryption is also much faster and less expensive to compute than asymmetric encryption while still offering comparable security.

In order to generate or exchange a random key that will be used to symmetrically encrypt the remaining portions of the connection, asymmetric encryption is only used during the initial handshake.

The random key can be made and exchanged in two different ways:

1. In this case, the cipher is sent encrypted to the server and the key is generated randomly by the client and encrypted with the server’s public key.
2. This calculation can be done on both sides and produces the same cipher, so the cipher itself never needs to be transferred. (This is known as the Diffie-Hellman key exchange) Both parties agree on a random value and derive a shared secret using this random value, their own private key, and the other party’s public key.

Only when both parties possess a key pair is the second strategy effective. Since you don’t need a key pair to visit HTTPS-encrypted websites, the first method is typically used when you’re browsing a website from your computer.

How can asymmetric encryption be used for authentication?

If you know a server’s public key, you can challenge it to prove that it has the correct private key. You can encrypt a random message and send it to the server, asking it to decrypt it for you, using the known public key. If the known public key and the private key on the server are the same, the decrypted message sent back by the server will match the encrypted message.

This indicates that you can put your trust in the server’s authenticity because, if it weren’t, it wouldn’t have a private key that matches the public key that you already know. This is how the known_hosts file for ssh works.

There is, however, another way of authenticating the other party. When you’re browsing the web, you do not have a list of known public keys for each server on the internet.
Therefore, the server sends you its public key upon initial connection. However, how can you be certain that this key really belonged to the server you were expecting? After all, you could be trying to access www.myimaginarydomain.com and an attacker diverts your calls to their own server.
The solution to this problem is quite easy: the operator of www.myimaginarydomain.com can use a public key that has been signed by a private key, whose public key is already installed on your system. “Certification authority” (CA) certificates are what these public keys are known as. However, there are times when it is more difficult because the CA certificates themselves are almost never used to sign “end-user” certificates directly; instead, they are used to sign intermediary certificates, and the entire chain can be validated.

For example, the certificate for www.myimaginarydomain.com might be signed by “Imaginary Corporation CA”, which might be signed by “Imaginary Global Trust Corporation”. If the Certificate of “Imaginary Global Trust Corporation” is part of your systems’ or browsers’ certificate store, then the certificate delivered by the server www.myimaginarydomain.com will be trusted by your system.

In the end, a connection will only be trusted if the other parties’ address matches the address contained in the certificate. If www.myimaginarydomain.com uses a certificate intended for www.notmyimaginarydomain.com, no connection will be established.

Nomenclature in the world of TLS

Although it’s simple to think of everything we’ve just discussed in terms of public and private key pairs, there are some terms that are frequently used when discussing TLS. In fact, everything we’ve just discussed is nothing more than that, aside from some metadata and signatures.

• In common parlance, a public key is referred to as a “certificate.” There are server certificates, which can be used to identify a server and send encrypted messages to them, and client certificates, which can be used to do the same thing, but with everything going in the direction of the client.
• In the context of TLS, a private key is frequently referred to as a “key.”
• A Certificate Authority (CA) is a body (an organization or an individual) that signs other certificates; if you trust this CA, you can trust certificates signed by them.
• A CA Certificate is a public key that is a part of a private key that is used by the CA to sign other certificates.
• The user creates a key and a Certificate Signing Request (CSR), which contains the public key and the domain or IP address that this certificate should be used for, in order to have a certificate signed off by a CA.
• For client certificates, the Common Name (CN) field frequently contains a username in addition to the domain name or IP address of the server that will be using the certificate.

Further reading

We suggest reading our practical content about setting up client / server encryption in PostgreSQL using SSL if you want to learn more about security.

An entire PostgreSQL instance may occasionally need to be completely encrypted. To further strengthen the security of the backend of your application, PostgreSQL Transparent Data Encryption (TDE) can do just that.

About Enteros

​​​​Enteros offers a patented database performance management SaaS platform. It finds the root causes of complex database scalability and performance problems that affect business across a growing number of cloud, RDBMS, NoSQL, and machine learning database platforms.