Day 20: How SSL/TLS Works 🔒

Understanding how data is secured over the internet is non-negotiable for any tech professional. Today was a deep dive into SSL/TLS, the protocol that puts the "S" in HTTPS.

Key Takeaways:
1️⃣ HTTP vs. HTTPS: HTTP sends all data (even passwords!) in plain text, making it easy for hackers to "sniff." sniffing. HTTPS fixes this by using TLS (Transport Layer Security) to create an encrypted, secure channel between your browser and the server.
2️⃣ Hybrid Encryption: TLS cleverly uses both types of encryption. It starts with slower Asymmetric Encryption (a Public/Private key pair RSA) to only verify the server's identity (via a Certificate) and securely exchange a new, temporary Symmetric Key.
3️⃣ The Handshake: This initial process is the "TLS Handshake." Once complete, the rest of the session uses that super-fast Symmetric Key ⚡ to encrypt all the actual data (your logins, form data, etc.).
4️⃣ Simple Analogy: A server's Public Key is like an open padlock 🔓 it gives to everyone (inside its Certificate). You put your secret session key in a box, lock it with their padlock, and send it. Only the server has the matching Private Key 🔑 to open the box.
5️⃣ Why this matters: This is the foundation of internet trust. It prevents Man-in-the-Middle (MITM) attacks, protects user credentials 🛡️, and ensures data integrity. In DevOps, we are responsible for managing and automating these certificates for our services (e.g., in Kubernetes Ingress or Load Balancers) to keep our applications secure.

Day 20: How SSL/TLS Works 🔒

This document explains the "why" and "how" of SSL/TLS (Secure Sockets Layer / Transport Layer Security), the technology that powers HTTPS.

The Problem: The Insecure Internet (HTTP)

In a basic client-server model, you (the client) send requests (like GET, POST, PUT) to a server.

When you use plain HTTP (Hypertext Transfer Protocol), this communication is in plain text.

Let's say you try to log in to a website:

Client ➡️ Server: POST /login (Username: "gaurav", Password: "pa$$w0rd123")
Server ➡️ Client: HTTP 200 OK (Here's your data...)

A hacker 🕵️ "sniffing" the network (e.g., on the same public Wi-Fi) can read this entire request. They now have your credentials. This is especially dangerous for banking, insurance, or any confidential site.

Attempt 1: Symmetric Encryption (A Good First Try)

What if we encrypt the data?

Idea: We can use a single symmetric key (a secret password) that both the client and server know.
Process:
1. Client: Encrypts the login data with my_secret_key.
2. Client ➡️ Server: "Here is the encrypted data."
3. Client ➡️ Server: "P.S. The key to decrypt it is my_secret_key."
The Flaw: The hacker simply sniffs the network, intercepts the key, and then decrypts the data. We're back to square one.

Attempt 2: Asymmetric Encryption (Getting Warmer)

This method uses a key pair:

Public Key 🔑 (Sharable): This key can only encrypt data. You can give it to anyone.
Private Key 🤫 (Secret): This key can only decrypt data encrypted by its matching public key. You never share this.

Now, the server can generate a key pair.

Process:
1. Server: Generates a public/private key pair (e.g., using openssl).
2. Client: "Hi, I want to talk."
3. Server ➡️ Client: "Great! Here is my Public Key 🔑."
4. Client: "Awesome. I will generate a new Symmetric Key (let's call it the session_key)."
5. Client: "I'll use your Public Key to encrypt my session_key."
6. Client ➡️ Server: "Here is the encrypted session_key."
7. Server: "Got it. I'll use my Private Key 🤫 to decrypt it."
8. Result: Both client and server now have the same secret session_key!

All future communication is encrypted using this fast symmetric session_key. The hacker can't intercept it, because even if they steal the encrypted package (in step 6), they don't have the server's private key to decrypt it.

The New Problem: The "Man-in-the-Middle" (MITM) Attack

What if the hacker is more clever?

Client: "Hi Server, I want to connect."
Hacker: (Intercepts the request) "Hi Server, I want to connect."
Server ➡️ Hacker: "Hi! Here is my REAL Public Key 🔑."
Hacker: (Saves the real key). "Hi Client! I'm the server. Here is my FAKE Public Key 🔑."
Client: "Looks good! I'll encrypt my session_key with your FAKE Public Key."
Client ➡️ Hacker: "Here is the encrypted session_key."
Hacker: (Uses their FAKE Private Key 🤫 to decrypt it). "Aha! I have the session_key!"
Hacker: (Re-encrypts the session_key with the REAL Public Key).
Hacker ➡️ Server: "Here is the encrypted session_key."

Result: The hacker is now an invisible proxy. They decrypt all your requests, read them, re-encrypt them, and send them to the server. You think you're secure, but you're not.

The Real Solution: SSL/TLS and Certificates 📜

How does the client know the Public Key it received actually belongs to the real server?

Answer: A Certificate Authority (CA) — a globally trusted third party (like DigiCert, Let's Encrypt, etc.).

This introduces trust.

Server: The server administrator (e.g., a DevOps engineer) generates a CSR (Certificate Signing Request). This file contains the server's domain name (google.com) and its Public Key.
Server ➡️ CA: "Hi [DigiCert], please validate that I own google.com and sign my CSR."
CA: The CA performs validation (e.g., checks DNS records, sends an email) to prove the server's identity.
CA ➡️ Server: "All good! ✅ Here is your official, signed SSL Certificate."

This certificate is a public document that essentially says: "We, [DigiCert], swear that the public key inside this file belongs to [https://www.google.com/url?sa=E&source=gmail&q=google.com]."

The Final HTTPS Handshake (Putting It All Together)

Now, let's try that connection again, this time with HTTPS:

Client (Browser): "Hi Server, I want to connect securely." (This is the Client Hello)
Server: "Hi! Here is my SSL Certificate 📜."
Client (Browser): "Hmm... let me check this certificate."
- "Is it for the correct domain (google.com)? Yes."
- "Is it expired? No."
- "Is it signed by a CA I trust (like DigiCert)? Yes! My browser has a built-in list of trusted CAs."
Client (Browser): "I trust you! ✅ This public key is legit."
Client: "I will now generate a random Symmetric Key (the session_key)."
Client: "I'll encrypt this session_key using the server's trusted Public Key (from the certificate)."
Client ➡️ Server: "Here is the encrypted session_key."
Server: "Got it. I'll use my Private Key 🤫 to decrypt it."
Result: Both client and server securely established a shared session_key.
Connection Secured: All further GET/POST requests are now encrypted with this symmetric key.

If a hacker tries the MITM attack again (Step 4 in that scenario), they can't provide a valid certificate for google.com signed by a trusted CA. The browser will immediately stop the connection and show a big red security warning ⚠️.

What about Intranet / Internal Sites?

For internal-only applications (e.g., a company dashboard), you don't need a public CA. The organization can create its own Custom CA. This custom CA certificate is then manually installed on all employee computers, telling their browsers to trust it. The process is the same, but the "root of trust" is the company itself, not a public entity.

Tech-Gen

Search This Blog