Before we jump into TLS, certificates, and all the “why is my browser yelling at me” stuff… we need to get one thing straight:

How encryption actually works underneath?

There are two types of encryption you’ll see everywhere:

• Asymmetric
• Symmetric

Symmetric Encryption (Same Key, Both Sides) Link to heading

This is the simpler one. This is where you and I share a secret key.

• I encrypt using that key
• You decrypt using the same key

Encrypt(message, key) -> ciphertext
Decrypt(ciphertext, key) -> message

It’s useful because it’s really fast—like, very fast—and that makes it great for handling large amounts of data without slowing things down. Also note that in context of this series, it typically is used after a connection has already been established.

Asymmetric Encryption (Two Keys, On Each Side) Link to heading

In this one… Instead of sharing one secret key, you have a pair of keys:

• A public key (you can give this to literally anyone)
• A private key (this never leaves your machine)

Encrypt(message, public_key) -> ciphertext  
Decrypt(ciphertext, private_key) -> message  

So unlike symmetric encryption, I don’t need to secretly share a key with you beforehand. You can just publish your public key openly, and anyone can use it to send you something securely (coz the message can be only decrypted with my private key, which I haven’t shared with anyone). But there’s a catch — this is much slower compared to symmetric encryption. Like, noticeably slower. So you don’t really use this to encrypt large amounts of data directly.

The obvious problem Link to heading

Which one to pick for TLS communications? I mean Asymmetric can be slow for every request / response to server and symmetric needs a pre-shared key (transferred via the network).

Say, if I send you an encryption key (symmetric) over the network, you’re not sending it through some private tunnel — it’s hopping across routers, servers, ISPs, maybe even crossing countries. And at any point along that path, if someone is watching the traffic, they can see EXACTLY what you sent… Anyone listening on the first connection (for pre-shared key) now also has the key 💀 Therefore, symmetric encryption can’t alone be used.

The solution Link to heading

This is exactly the gap that asymmetric encryption fills. Instead of trying to secretly send a key directly, a server sends it public key over the network (it’s meant to be public so no problem in sharing it). The client chooses a symmetric key of it’s choice and encrypts it with the public key of server. This encrypted symmetric key is then shared across network.

NOW, only the party having server’s private key can choose to decrypt it, which ensures that symmetric key (even if someone’s monitoring the network) can’t be obtained as it’s encrypted and can’t be used before it’s decrypted using the private key. This is known as RSA Key Exchange.

From there on, every request sent over the network is sent in encrypted format using symmetric key saving time for compute on RSA encryption.

The modern solution Link to heading

The solution above was good. But this is not how modern TLS works. Above mentioned was a rough idea of how SSL encryption used to work. In modern days (since TLS 1.2) with TLS 1.3 and ECDHE, the symmetric key is NEVER SHARED ACROSS THE NETWORK IN ANY FORM. It is computed locally on both ends using server’s and client’s, public / private keys.

They use a key exchange mechanism (like Diffie-Hellman, usually elliptic curve version) which uses some cool math algorithms to take some random temporary values and public keys of both client and server (which are transmitted over the network) to compute a symmetric key together with their OWN private keys to compute the shared symmetric key.

Private Key (Server) * Public Key (Client) * Temporary Value (Shared)

Private Key (Client) * Public Key (Server) * Temporary Value (Shared; Same as above)

Private Key (Server) * Public Key (Client) * Temporary Value == Private Key (Client) * Public Key (Server) * Temporary Value

Btw, What is the difference between SSL and TLS? Link to heading

SSL came first. Netscape built it in the 90s (when the web was still figuring itself out), It did the job, but it had a bunch of design issues that only really became obvious later. SSL 2.0 was outright broken, SSL 3.0 was better but still flawed and eventually things like the POODLE attack made it clear that this line of protocols had to go.

TLS is what came after, though it’s not a completely different idea — it’s more like someone took SSL, cleaned it up, standardized it properly, and kept improving it version by version. TLS 1.0 was basically “SSL 3.1”. Then, TLS 1.2 tightened a lot of cryptographic choices. TLS 1.3 went even further — simplifying the handshake, removing old insecure algorithms entirely, and making things faster and more secure at the same time. TLS (at 1.3) is a lot different than what SSL used to be

So yes, today SSL and TLS are completely different ideas… Start calling it TLS certificate than SSL certificate. 😉

Thank You For Reading Far. Link to heading

This one goes towards a major new series I am writing Encryption In Transit. So, if you’d like to double down more on such stuff kindly follow along. Or reach out to me on X and tell me how ugly I am with my writing skills and need to better change careers into Hydroponic farming 😄