Pull up a chair, grab your lunch, and letâs go on a journey. Imagine the internet as an airport â yes, the whole thing. Millions of people (data packets) flying around daily, hopping on planes (networks), trying to reach their destinations. But hereâs the catch: without passports, visas, and security guards, this airport would be pure chaos.
Thatâs where SSL and TLS come in. And lucky for us, they work a lot like the passport application process.
What Even Is the Network?
(âWait, who owns this airport anyway?â)
When you send or receive information on the internet, your data doesnât fly directly from your laptop to your favorite social media app server. Nope. It hops through a whole chain of connecting flights:
-
Your Wi-Fi router (local shuttle bus)
-
Your ISPâs backbone (regional airport)
-
Submarine cables or satellite relays (international flights)
-
Data center routers and switches (immigration checkpoints)
This interconnected web of stops is what we simply call âthe network.â Itâs like flying from Lagos to San Francisco with three layovers: every hop matters, every stop is a physical device forwarding your data like airport staff passing you along.
And just like in airports, if your passport is transparent, every guard along the way can read your secrets. Historically, thatâs exactly what happened, data was sent in plain text.
How a Normal Flight (Request) Works
(âOkay, show me your documents.â)
Hereâs what happens when you type https://example.com
into your browser:
-
DNS Resolution: You ask the Directory Office where Example Airlines is located. This is the DNS server handing you the IP address (like giving you the terminal and gate number).
-
TCP Handshake: Before boarding, you and the airline shake hands:
- SYN: âHey, I want to fly.â
- SYN-ACK: âCool, weâre ready for you.â
- ACK: âGreat, letâs go.â The connection (your boarding gate) is open.
-
TLS Handshake: Now the airline (server) pulls out its passport (TLS certificate). But wait â you (the client) are the border officer here. Itâs your job to check the airlineâs documents.
Why the Client is the Border Guard
(âPapers, please!â)
Think about it:
- The server already knows who it is.
- But you (the traveler) need to confirm youâre boarding the right flight, not being scammed by some shady airline named âExampl3.com.â
So your browser inspects the airlineâs passport:
- đ Is it signed by a recognized passport authority (CA)?
- đ Does the name match (example.com)?
- đ Is it still valid, not expired?
- đ Has it been revoked for fraud?
If everything checks out, the officer (your browser) stamps âApprovedâ and the flight proceeds. If not, you get the dreaded red browser warning screen: âThis airlineâs passport is fake, do not board!â
Who Issues the Passports? (CAs)
(âWho gave you this passport, anyway?â)
Enter the Certificate Authorities (CAs) â the global passport offices of the internet.
Some famous ones youâve probably âflown withâ:
-
DigiCert (the fancy old-school embassy)
-
GlobalSign (the veteran official)
-
Letâs Encrypt (the cool nonprofit giving out free passports)
-
Google Trust Services (GTS Root R1âR4. Yep, Google runs its own passport office)
When a server applies for a passport (certificate), hereâs what happens:
-
The server generates a private key + public key pair (like posing for ID photos).
-
It submits a Certificate Signing Request (CSR) (like filling out the application form).
-
The CA verifies identity (domain control, org documents, etc.).
-
The CA signs and issues the passport (TLS cert).
Now your server can fly across the internet without suspicion.
But What About DNS?
âEven the directory office needs passports.â) DNS is the directory desk in this airport analogy. Traditionally, DNS queries were shouted across the terminal:
- âHEY, WHERE IS EXAMPLE.COM?â
- Anyone nearby (hackers, shady guards, curious fellow passengers) could hear you.
Thatâs because DNS ran over plain UDP port 53, no encryption, no passports. Modern fixes:
DNS over HTTPS (DoH): Wraps DNS queries inside HTTPS (TLS), now you whisper in a private booth. DNS over TLS (DoT): Same idea, dedicated TLS-encrypted channel on port 853. DNSSEC: Adds signatures to prove records havenât been tampered with (like a notarized directory).
So yes, DNS servers are also âairlines,â and when you use DoH/DoT, they show their passports too.
SSL vs TLS â The Naming Mess
(âWhy do old guards still say SSL?â)
Now, hereâs the twist. Back in the 90s, Netscape invented the first passports: SSL (Secure Sockets Layer).
- SSL 2.0 and 3.0 were full of holes (think fake lamination, easily forged).
- In 1999, the IETF stepped in and issued new passports under a new standard: TLS (Transport Layer Security).
But old habits die hard. People still call them âSSL certificatesâ even though everyone is really using TLS now.
Today:
- SSL is dead and buried.
- TLS 1.2 and TLS 1.3 are the valid passports.
- TLS 1.3 is the cool new biometric passport: faster, cleaner, only strong crypto allowed.
The Whole Journey Recap
Letâs recap your packetâs journey through the airport of the internet:
-
DNS (Directory Office): Whereâs Example Airlines?
-
TCP Handshake (Boarding Gate): Do we agree on a communication channel?
-
TLS Handshake (Passport Control): Server shows passport, client verifies.
-
Encrypted Flight (Data Transfer): You fly safely across networks, nobody can peek inside.
-
Arrival: The server decrypts and delivers your webpage.
And all this happens in milliseconds while youâre scrolling memes at lunch. đ„Șđ
Final Thoughts
The next time you hear âSSL/TLSâ or âHTTPS,â just picture a giant airport where every packet needs a passport. The CAs are the passport offices, your browser is the border guard, and TLS is the shiny biometric passport that ensures no shady imposter airline flies off with your secrets.
Without TLS, the internet would still be like mailing postcards â fun for the postman, terrible for privacy.
So next time Chrome asks if you really want to âproceed without a valid certificate,â remember: thatâs like sneaking onto a shady plane with a fake passport. And honestly, who wants that adventure?