Understanding TLS: how data stays secure over the internet

How the TLS protocol works under the hood and why it's important.

Hi Friends,

Welcome to the 122nd issue of the Polymathic Engineer newsletter.

If you have ever thought about how your credit card information gets sent safely or your messages stay private over the internet, part of the answer is the transport layer security protocol (TLS).

This week, we discuss such protocol in detail:

• What is the TLS protocol

• The Three Pillars of TLS Security

• The TLS Handshake Process

---

Project-based learning is the best way to develop technical skills. CodeCrafters is an excellent platform for practicing exciting projects, such as building your version of Redis, Kafka, DNS server, SQLite, or Git from scratch.

Sign up, and become a better software engineer.

---

Introduction to TLS

TLS is a protocol that lets applications safely communicate over a network. It works like a secure link between your device and another computer. No one can stop, halt, or change the information going through.

The idea is to enhance application-level protocols with security features like integrity, identification, and encryption. This is why you use TLS every day, and you don't even realize it most of the time.

When you see a padlock icon in your browser's address bar, you’re on a page that uses HTTPS, which is just HTTP running on top of TLS. That's not all, though. TLS is also used by other secure protocols, such as FTPS for file transfers and SMTPS for email, to keep your data safe.

Modern tools take care of much of the complexity that makes TLS hard for developers and system admins. However, learning how TLS works isn't just for school — anyone who builds or uses online apps where security is important needs to know this.

The Three Pillars of TLS Security

TLS secures communication through three main features: encryption, authentication, and integrity. Let's see how each one works.

Encryption makes sure that only the two communicating processes can read the data that is being sent. TLS does this using a smart two-step approach.

Asymmetric encryption starts by creating a key that both processes can use. This type of encryption uses public-private key pairs and complex math operations to establish a safe connection without directly sending the secret key over the network.

After that, symmetric encryption is used to send and receive data. This switch is because asymmetric encryption takes a lot longer and requires more computer power, even though it is safer. Symmetric encryption is faster and more effective for ongoing communications.

The system regularly negotiates the shared encryption key so that damage is limited if a key is compromised. Modern processors have special instructions for encryption, so it doesn't slow things down much. This is another reason why TLS protocol should be used everywhere, not just for internet traffic.

Authentication lets the communicating processes make sure they are who they claim to be. TLS implement this with digital signatures based on asymmetric cryptography.

The server makes a key pair and gives the client its public key. When the server sends messages, it signs them with its private key. The client can then use the public key to check these signatures.

But how does the client know that the public key is real? This is where the certificates come in. A certificate shows that someone owns a public key. It has information about the owner, an expiration date, and a digital signature from a certificate authority (CA) that granted it. Servers send their certificate chains to your device when you connect to them. Your system checks this chain until it finds a known root CA that is already on your device.

A common mistake is letting certificates expire. If this happens, clients can't check the server's name, and connections fail. Since this can bring down whole applications, keeping an eye on certificates and renewing them automatically is essential for any production system.

Even data that is encrypted could be changed while it is being sent (i.e., tampered). A message authentication code (HMAC) used by TLS checks the integrity of the data to stop this from happening.

This is how it works: the sender uses a private hash function to make a digest of the message and sends it along with the message. The receiver figures out the digest again and compares it to the sent one. If they don't match, the message has been messed up and gets thrown away.

The integrity check is an extra safety measure on top of what TCP already does. TCP's checksum can find faulty data, but TLS's method is more thorough because it finds both accidental errors and intentional changes.

The TLS Handshake Process

Before it can connect clients to a safe website, TLS has to set up a safe route. This procedure is called handshake and takes place before any data is sent. During the handshake, the client and server agree on a safe way to talk to each other.

The first thing they do is choose a collection of algorithms that handle different security tasks. This cipher suite includes the following:

• The key exchange algorithm to create a shared secret

• The signature algorithm for certificate verification

• The symmetric encryption algorithm for protecting the actual data

• The HMAC algorithm to make sure data isn't tampered with

Next, they use the key exchange algorithm to create a shared secret. The symmetric encryption algorithm will use this secret to protect all future communications.

The client also checks the server's certificate during this time to make sure the server is really who it claims to be. The client can then send encrypted data to the server if everything checks out.

Sometimes, the server might also check the client's certificate, but this isn't always necessary. It depends on how the server is set up and what kind of security is needed.

The handshake process has gotten more efficient over time. With TLS 1.2, it typically needs two round trips (messages back and forth) to complete. The newer TLS 1.3 has improved this to just one round trip, making connections faster.

Even with these improvements, creating a new TLS connection still takes time. This is why using connection pooling in high-traffic applications is good practice.

The handshake might seem complicated, but modern libraries and frameworks handle all these details for you. As a developer, you rarely need to worry about the low-level details - but understanding how it works helps you make better security decisions for your applications.

Interesting Reading

Here are some interesting articles I read in the past days:

• From Typing URL To Showing the Webpage by

  Saurabh Dashora

• When Time Is Short, Choose Boring Tech by

  Riccardo Causo

• Every Outbox Needs an Inbox by

  Raul Junco