Imagine you’re visiting a website—say your bank’s website mybank.com. You type your username and password, hit enter, and your credentials are sent to the web server for authentication. Now this data travels across the network as plain text. A hacker sniffing over the network in a coffee shop, for instance can easily see your sensitive information travelling to the web server and can easily misuse it.
Your passwords, credit card details, and personal information are vulnerable to theft. The trust between users and websites is compromised. Clearly, sending data as plain text is a terrible idea.
Therefore we encrypt the data and then send it over the network.
What we do is, the sender i.e you encrypts the data with a key (a secret code) and sends it to the server. But now the server needs to decrypt it back with the same key you used to encrypt it, so you need to send the key as well over the network to the server, so that server can decrypt the data.
Till now you would have get the problem in symmetric encryption, by the way this is called symmetric encryption where a single key is used to both encrypt and decrypt data.
Now you may have a doubt but I don’t encrypt any data with any key, this work is automatically been taken care of by your web browser.
Now back to the topic, lets revisit that example of the bank’s website.
Your browser encrypts your credentials using the key.
The encrypted data is sent to the server along with key so that server can decrypt the data.
The server decrypts it using the same key.
The problem is the hacker sniffing over the network also can get the key when it’s sent to the server, and can also decrypt the credentials, now we are back with the same problem again.
Asymmetric Encryption: Solving the Key Sharing Problem
As we discussed earlier, symmetric encryption has a major flaw: the key used to encrypt and decrypt the data has to be shared between the sender (your browser) and the receiver (the server). If a hacker intercepts this key, they can decrypt all your data.
To solve this, we turned to asymmetric encryption, or public-key cryptography. The word "cryptography" comes from the Greek word kryptos, which means "hidden". It is the science of hiding or coding information so that only the intended recipient can read it.
The beauty of asymmetric encryption lies in the use of two keys:
A public key: This is shared with anyone and can only be used to encrypt data.
A private key: This is kept secret by the server and can only be used to decrypt data.
The keys are mathematically linked, meaning that whatever is encrypted with the public key can only be decrypted with the corresponding private key—and vice versa.
NOTE: We can’t encrypt and decrypt with the same key, if we encrypt using one key then we need the other to decrypt it. Therefore we mostly encrypt with public key.
How Asymmetric Encryption Works (Back to the Bank Example)
Let’s revisit your journey on the bank’s website:
The Public Key Exchange:
When you visit securebank.com, the server sends its public key to your browser along with its SSL certificate. Don’t worry we will talk more on SSL certificates in the next section.
Your browser uses this public key to encrypt your sensitive data (e.g., username and password).
Data Encryption:
Suppose your password is
MySecurePassword123.Using the public key, your browser converts it into an unreadable format (ciphertext), something like this:
7Gd#9Xs&JqZ!2P*This ciphertext is then sent to the server.
Private Key Decryption:
The server, holding the private key, decrypts the ciphertext back into its original form:
MySecurePassword123.Even if a hacker intercepts the ciphertext, they won’t be able to decrypt it because they don’t have the server’s private key. All that hacker is left with is public key and encrypted credentials.
Why Asymmetric Encryption Works
The genius of asymmetric encryption is its one-way nature for the public key. Anyone can use it to encrypt data, but only the server’s private key can decrypt it.
Even if the public key is intercepted, it’s useless without the private key. This solves the key-sharing problem we faced with symmetric encryption as we have 2 keys here. The whole idea is to prevent the hacker getting the key, so we made 2 keys one to encrypt and one to decrypt, even if the hacker gets the public key it can only encrypt the data not decrypt it, so its useless for him.
But There’s a Catch...
Asymmetric encryption is incredibly secure, but it’s also computationally heavy. Encrypting and decrypting every piece of data this way would slow down communication significantly, especially for large-scale websites with millions of users.
So, while asymmetric encryption is great for securely sharing sensitive information, we needed a more efficient way to handle ongoing communication.
The Hybrid Model: Using Both
Instead of using asymmetric encryption for everything, we uses it only for the initial handshake—the process of securely sharing a session key.
The session key is a temporary, random key used for symmetric encryption. Once it’s securely shared using asymmetric encryption:
Your browser and the server switch to symmetric encryption for the rest of the session.
This makes communication fast while still being secure, as the session key was shared safely.
In simple words we use asymmetric encryption to share the session key with the server and once the server gets it, we switch back to the symmetric encryption.
The Role of Certificate Authorities (CAs): Who Can You Trust?
Now that we’ve discussed encryption, let’s address another question:
How do you know the server’s public key actually belongs to the website you’re visiting?
Imagine this scenario:
A hacker creates a fake website that looks exactly like your bank’s site, complete with a public key.
If you mistakenly encrypt your data using the hacker’s key, they can decrypt it and steal your credentials. You must have seen this, when this error appears, your browser is warning you that it cannot verify the website’s identity.
This is where Certificate Authorities (CAs) come in.
What Are Certificate Authorities?
CAs are trusted organizations that verify the identity of websites. They act like digital notaries, issuing SSL certificates to websites after verifying their legitimacy. It helps to claim that the server is who they claim they are.
When you visit a website:
Your browser checks the SSL certificate provided by the server.
The certificate confirms the website’s identity and links it to the public key.
If the certificate is valid and issued by a trusted CA, your browser establishes a secure connection. If not then it gives the above error of not being secure which then we should not visit.
Why CAs Are Important
Without CAs, there would be no way to distinguish between legitimate websites and imposters. By acting as a trusted middleman, CAs ensure that your encrypted communication is with the correct server.
To sum up, What Is SSL?
At its core, SSL(Secure Socket Layer) is a protocol designed to secure communication over the internet. It ensures that:
Data sent between your browser and a server is encrypted, making it unreadable to anyone who might intercept it.
The server you’re communicating with is authentic, so you’re not accidentally sending sensitive information to a malicious actor who claims to who they are but are not that actually.
An SSL certificate is like an ID card for a website. It contains:
The server’s public key.
Information about the website’s domain and organization.
A digital signature from a trusted Certificate Authority (CA) that verifies the certificate’s legitimacy.
While SSL revolutionized online security, it’s worth noting that it’s now considered outdated due to vulnerabilities in older versions. Today, we use TLS (Transport Layer Security)*, which is the improved and more secure version of SSL. Despite this, the term "SSL" is still widely used to refer to SSL/TLS.*