The Invisible Shield Behind Every HTTPS Request — Understanding TLS From First Principles

In the previous article, we talked about how computes communicate with each other reliably over network using IP, TCP, routing, congestion control and sockets but what is stopping anyone from reading or modifying the date? The answer is Transport Layer Security(TLS).

Communication Alone Isn’t Enough

Imagine sending a postcard, every post office employee can read what’s written.Now imagine sending your credit card number the same way, probably not a great idea!

The Internet behaves similarly.

When your data leaves your computer, it doesn’t magically jump to the destination.Instead it passes through multiple routers.

Laptop
   ↓
Home Router
   ↓
ISP
   ↓
Internet Backbone
   ↓
Cloud Provider
   ↓
Server

Every one of these devices forwards your packets. Without protection, anyone capable of observing the traffic could potentially read it.

Distributed systems constantly exchange:

• passwords
• API tokens
• payment information
• database queries
• authentication cookies

Sending these in plain text would be disastrous.So we need three guarantees.

The Three Problems TLS Solves

Whenever two machines communicate securely, they need to answer three questions.

1. Can anyone read our conversation?

This is the problem of Confidentiality. Solved using Encryption.

2. Are we really talking to the correct server?

This is Authentication. Solved using Certificates.

3. Has anyone modified the message while it was travelling?

This is Integrity.Solved using Hashing and Message Authentication Codes (HMAC).

Everything TLS does, revolves around solving these three problems.

Where Does TLS Fit?

In the previous article we learned that applications communicate using TCP. TLS sits on top of TCP.

The application doesn’t need to worry about encryption. TLS handles everything automatically.

Step 1 — Encryption

Suppose Alice wants to talk securely with Bob.

If Alice simply sends an encryption key across the network…

Client
   |
Shared Secret
   |
Internet

Anyone listening now has the key. Clearly that doesn’t work.

Instead TLS first performs asymmetric cryptography.

Each side owns two keys.

• Public Key
• Private Key

The public key can be shared with anyone. The private key never leaves the machine.

Using these public keys, both client and server independently calculate the same shared secret without ever sending that secret across the network.

This is one of the most beautiful ideas in modern cryptography. Even though the secret never travels over the Internet…

Both computers end up with exactly the same encryption key.

Why Doesn’t TLS Keep Using Public-Key Encryption?

Because it’s expensive.

Asymmetric encryption requires far more computation than symmetric encryption. Instead TLS only uses asymmetric cryptography to agree upon a shared secret.

Once both sides know that secret…

All remaining communication switches to fast symmetric encryption like AES.

This gives us both:

• secure key exchange
• high performance

The shared secret is also periodically renegotiated to limit the impact of a compromised key.

Step 2 — Authentication

Encryption alone doesn’t solve everything. Imagine an attacker intercepts the connection.

• They generate their own public key.

1. Then send it to you pretending to be your bank.
2. You’ll happily encrypt everything…to the attacker.

This is known as a Man-in-the-Middle (MITM) attack.

Simply receiving a public key doesn’t prove who owns it. So how does the browser know it’s really talking to your bank?

Certificates To The Rescue

Instead of saying

“Trust me, this is my public key.”

The server says

“A trusted third party has verified this public key belongs to me.”

That proof is called a Digital Certificate.

A certificate contains information like:

• Domain name
• Public key
• Owner
• Expiration date
• Digital signature from a trusted Certificate Authority (CA). Think of it as a passport for websites.

The Certificate Chain

When a TLS connection begins, the server sends more than just its own certificate.

It sends the certificate chain.

Your operating system or browser already contains a trusted store of Root Certificates. When the client receives the chain, it verifies it backwards.

• Is the Root CA trusted?
• Did it sign the Intermediate Certificate?
• Did the Intermediate sign the Server Certificate?
• Has any certificate expired?
• Does the certificate match the requested domain?

Only if every verification succeeds does the connection continue.

Otherwise…

The browser shows the dreaded

“Your connection is not private.”

or simply refuses the connection entirely.

This is why expired certificates can bring production systems down. Many engineering teams automate certificate renewal because forgetting to renew one can make an entire application inaccessible.

Step 3 — Integrity

Suppose nobody could read the message…but someone changed it.

That’s still dangerous.

Imagine changing of the operation below:

Transfer ₹100

into

Transfer ₹100000

Encryption alone doesn’t prevent tampering. TLS therefore attaches a Message Authentication Code (HMAC) to every message.

• The sender computes a hash of the message using the shared secret.

1. The receiver performs the same calculation.
2. If both values match, the message hasn’t changed.If even a single bit changes, the hash becomes completely different.

The message is immediately rejected which guarantees integrity.

Bringing Everything Together — The TLS Handshake

Before secure communication begins, client and server perform a TLS Handshake.

During this handshake they:

1. Agree on a Cipher Suite

This decides:

• which key exchange algorithm to use
• which encryption algorithm to use
• which hashing algorithm to use

2. Establish Encryption

Using asymmetric cryptography they securely negotiate a shared secret.

Afterwards they switch to symmetric encryption for speed.

3. Authenticate

The client verifies the server’s certificate chain using trusted Certificate Authorities.

4. Begin Secure Communication

Every subsequent message is:

• encrypted
• authenticated
• integrity protected

Only then does your HTTP request finally leave the browser.

Why Distributed Systems Depend on TLS

Modern distributed systems constantly exchange sensitive information. Microservices call each other thousands of times every second, databases replicate data, payment services exchange financial information, authentication servers issue access tokens and so much more..

Without TLS, every router between those services could potentially inspect or modify that communication.

TLS makes the network trustworthy enough that distributed systems can safely operate over infrastructure they don’t own.

That’s why you’ll find TLS almost everywhere:

• HTTPS
• gRPC
• Database connections
• Service meshes like Istio
• Kafka
• Kubernetes API Server

In distributed systems, secure communication isn’t an optional feature. It’s part of the foundation.

Final Thoughts

In the previous article, we learned how computers communicate. This time, we learned how they communicate securely.

TCP gives us reliable delivery. TLS adds confidentiality, authentication and integrity. Together they form the secure foundation upon which modern distributed systems are built.

The next time you see a small 🔒 icon in your browser, remember that within a few milliseconds your computer has negotiated encryption keys, verified certificate chains, agreed on cryptographic algorithms and established a secure channel — all before the first byte of your webpage is delivered.

And all of that happens so seamlessly that most of us never notice it.

Thank you for bearing with me till the end, if you liked the article, please follow my list here which is being updated with more articles and learnings from my System Design journey.

Note: This article is based on concepts learned from Understanding Distributed Systems book by Roberto Vitillo. The explanations, examples, and interpretations are presented as part of my learning journey and how i understood the concept but any credit goes to the original author for the foundational ideas.

💬 Why follow me here? If you’re into tech insights, interview/resume tips, self-improvement tips, and honest reflections about work and life, I think we’ll get along just fine. Hit Follow so we can learn from each other! You can also follow me on LinkedIn and contact me from any of the options below: