HTTPS: Built on Trust Issues
Trust is fragile. We humans know this better than any other species — shaped by stories of betrayal, and by betrayals we’ve suffered firsthand. But on the internet, are we really expected to just... believe?
Behind every padlock icon in your browser is a leap of faith — one engineered, signed, and chained by systems built for paranoia. Because here, only the paranoid survive.
You open your browser and type “gmail.com”, which takes you to the Gmail login page. To check your email, you enter your username and password, then click “submit.”
Your computer establishes a connection with a remote Google server, which could be located anywhere in the world. The data you entered travels through wireless signals, cables, and optical fibers, transmitted as streams of binary digits. This data covers hundreds or thousands of miles before reaching Google’s servers.
On its journey, your information passes through many networks and devices, any of which could be vulnerable to hackers. Without proper security, your sensitive data could be intercepted and stolen, putting your privacy at risk.
This was the problem with HTTP — which stands for Hypertext Transfer Protocol. People were uncomfortable knowing that anyone could easily intercept their login credentials or sensitive data while it traveled across the internet. That’s a huge security risk.
That’s exactly why HTTPS was created — to fix this vulnerability and keep your information safe.
HTTPS - HyperText Transfer Protocol Secure
Encryption protects you?
The very creatively named HTTPS encrypts your traffic using a secret key — a key known only to you and Google’s servers. This ensures that even if someone intercepts your data, they can’t read it without that key.
Here’s an example of encryption using AES (Advanced Encryption Standard), a widely trusted and strong encryption algorithm.
I encrypt the message on my side using the key "THIS_IS_THE_KEY_", and when I decrypt it with the same key, I get back the original data. But if I try to decrypt it using the wrong key, the output is just a meaningless jumble — the actual data stays hidden, unreadable to anyone without the correct key.
This system, known as symmetric encryption, assumes a shared key already exists—which isn’t practical. We can’t have a unique shared key with every server we connect to. So, we need a way to share the key securely without exposing it. If a hacker intercepts the key during an initial exchange, or if we have to send the key along with the message, the whole encryption and decryption process becomes pointless
Asymmetric Encryption to the rescue!
Asymmetric encryption solves the core problem of symmetric encryption: securely sharing a key over an untrusted network. Instead of relying on a shared secret key, the server generates a key pair — a private key (kept secret) and a public key (shared openly).
When the client wants to send data securely, it encrypts the message using the server’s public key. Even if a hacker intercepts the encrypted message, they can’t decrypt it without the server’s private key. Only the intended server can decrypt the message, ensuring confidentiality.
In a typical secure communication scenario, the client generates a random symmetric key intended for encrypting the bulk of the data efficiently. This symmetric key is then encrypted using the server’s public key, ensuring that only the server, holding the corresponding private key, can decrypt it. Once the server recovers the symmetric key, both client and server share this secret, enabling them to communicate securely with fast symmetric encryption. This hybrid approach leverages the strengths of asymmetric encryption to securely exchange keys, while relying on symmetric encryption’s superior speed and efficiency to protect the ongoing data exchange, thus maintaining both security and performance in real-world applications like HTTPS.
This model allows secure communication over the internet without the need to pre-share a secret key, and it’s the foundation of HTTPS. There's more though, because, we aren't safe yet :(
The Man-In-The-Middle Attack
A Man-in-the-Middle (MITM) attack is a powerful threat in online communication where an attacker secretly intercepts and possibly alters the data being exchanged between two parties — often without either side realizing it.
In the context of asymmetric encryption, imagine you try to connect to a website and request its public key (which can be shared openly). If a hacker is sitting between you and the server, they can intercept this request and send you their own fake public key instead.
You unknowingly encrypt your data with the attacker’s key, and now the attacker can decrypt your message, read it, and even re-encrypt it with the real server’s key — acting as an invisible bridge. Everything looks normal to you and the server, but the attacker is quietly eavesdropping or tampering with the communication.
It is hence important to verify the authenticity of the so-called server's public key. In an asymmetric encryption setup, the security of communication relies on the assumption that the public key received by the client truly belongs to the intended server. However, without a mechanism to verify the server’s identity—this assumption breaks down.
Who to Trust? Even Computers Struggle With That.
"Who to trust?"—a question as old as civilization. And surprisingly, even computers have a hard time answering it. In the digital world, we’ve had to build complex, delicate systems just to help machines decide who’s trustworthy. Today, we’ll peel back the layers on one of the most critical parts of that trust infrastructure: Certificate Authorities (CAs).
So, what's the problem? Let’s say you’re trying to talk securely with a website. The website hands you a public key and claims, “Hey, I’m legit.” But how can you be sure? Anyone could claim that. You need proof—evidence that this key really belongs to who it says it does.
Let’s bring this into the real world.
Recommended by LinkedIn
Imagine you get invited to a party at Bob’s house. But here's the thing—you’ve never met Bob. He says a mutual friend, Charlie, vouches for him, and even gives you a letter from Charlie that reads:
"Hey, don’t worry, Bob’s my friend. You can trust him. Go to his party."
Now, would you just take Bob’s word for it? Probably not. You’d want to make sure that letter really is from Charlie. You’d check for something only Charlie could add—maybe a signature, maybe a unique stamp.
In the digital world, that signature is exactly what a Certificate Authority provides.
If you pass an exam or win a competition, your school or the organizing committee gives you a certificate with their official seal. That seal is important—only they can issue it, and you can’t forge it. It’s what makes the certificate trustworthy.
Similarly, in the digital world, a Certificate Authority (CA) acts as a trusted third party that vouches for a website’s identity. It issues a certificate with its own cryptographic "seal of verification"—a digital signature that only the CA can create. This seal proves that the website is legitimate and that its public key truly belongs to it.
Let's dive in
The Server generates a public–private key pair.
The Server proves the ownership of a domain to the CA, using various techniques.
The Server sends to the CA its, Public Key, Server's Claims, Domain Name.
The CA signs and returns a Certificate to the server. This certificate contains: The server’s public key, server claims, a digital signature from the CA.
# Claims (Subject here is the Website)
Subject info (domain name, org, etc.)
Validity period
Subject's public key
Issuer info (the CA)
Signature = Encryption(Hash(Server's Claims + Server's Public Key), CA's Private Key)
It will also contain details like, which Asymmetric Encryption Algorithm was used and which Hashing Algorithm was used.
The Client connects to the server and gets this certificate during the TLS handshake, which is the process establishing a secure connection between the client and the server, before transmission.
Then the Client verifies the certificate,
Hash1 = Hash(Server's Claims + Server's Public Key) # Found in the certificate
Hash2 = Decrypt(Signature, CA's Public Key)
If Hash1 == Hash2, then the signature is verified.
If you’ve been following along, a major question should naturally pop into your head:
How can you trust the CA’s public key?
The answer lies in something called the Chain of Trust. A CA's public key is trusted because it has also been verified—by getting its certificate signed by another CA at a higher level. This forms a chain, where each certificate is vouched for by the one above it.
Eventually, this chain ends at the Root CA, which sits at the very top. Root CAs are special—they are implicitly trusted by your operating system or browser. Their certificates are self-signed, and they don't rely on any higher authority because they are the authority.
There aren’t many root CAs in the world, and they are subject to intense scrutiny and audits to maintain that trusted status.
Your browser, operating system, or app uses a list to decide which Certificate Authorities it trusts to verify websites, servers, or services. This list is called a trust store.
Fine chrome's root store here: chrome://certificate-manager/crscerts
A trust store is like a trusted contacts list that your device or software keeps to know whom it can believe. It’s a collection of trusted Root CA certificates (public keys + info).
When your browser sees a website’s certificate, it checks if the certificate’s chain leads back to a root CA in this trust store. If yes, the website’s certificate is considered valid and trustworthy; if not, you get warnings like This site’s certificate is not trusted.
The End of Internet Security
I cannot stress this enough: If a Major Root CA’s private key were ever compromised, it would be a nuclear-level event for the internet.
We’re talking instant collapse of trust—millions of secure connections, websites, apps, APIs… all thrown into chaos. Browsers would panic, users would be locked out, and threat actors could impersonate any website on the planet. It would be a field day for attackers and a nightmare for defenders.
So yeah—let’s all take a collective breath and pray that companies like DigiCert and Let’s Encrypt are guarding their private keys like the digital crown jewels they are. We're talking air-gapped, tamper-proof vaults, multi-person ceremonies, and hardware security modules locked down tighter than Fort Knox.
Because if that chain of trust ever breaks… The internet burns.
References
Attribution
Editorial Note: The foundational concepts and analogies were developed by me, with AI assisting in refining the language and enhancing the structure to improve clarity and engagement throughout the newsletter. Additionally, AI was used to generate some images based on detailed prompts.