Concepts: Threats, Encryption, HTTPS
The Threat Landscape in India
Before we talk about solutions, we need to understand what we are protecting against. The three most common threats you will encounter are phishing, ransomware, and man-in-the-middle attacks.
Phishing
Phishing is when an attacker tricks you into revealing information — your password, your OTP, your bank details — by pretending to be someone trustworthy.
You have seen the messages. “Your IRCTC account has been suspended. Click here to verify your KYC.” “Your SBI account will be blocked in 24 hours. Update your details now.” “Your email storage is full — click here to verify your account.”
What makes phishing work is urgency plus familiarity. The message looks real. The logo looks real. The link almost looks real (it might say sbi-update.online instead of sbi.co.in). And you are scared of losing your account, so you act fast without checking carefully.
Rajan bhaiya’s story was phishing — an email that looked like it came from a software company, with an attachment that turned out to be ransomware.
Ransomware
Ransomware is a specific type of attack where malware encrypts your files and demands payment to decrypt them. The attacker holds your data hostage.
The irony of ransomware is that the attacker uses encryption — the same technology that protects your data — against you. They encrypt your files with a key only they know. Unless you pay, you cannot read your own files.
Man-in-the-Middle (MITM)
A man-in-the-middle attack is when an attacker positions themselves between you and the server you are trying to reach, secretly reading or altering the data flowing between you.
Imagine writing a letter to your bank. Unknown to you, the postman opens every letter, reads it, copies it, reseals it, and delivers it. You and the bank think you are communicating directly. You are not.
On the internet, this can happen on unsecured public Wi-Fi networks. We will go deep on this in Session 4.
The Answer: Encryption
Encryption is the transformation of readable data into unreadable scrambled data that can only be unscrambled by someone with the right key.
The postcard vs the sealed letter:
When you send data over HTTP (without the S), it travels like a postcard. Every router, every ISP, every network device between you and the server can read the contents. Your username. Your password. Your message.
When you send data over HTTPS, it travels like a sealed letter. Even if someone intercepts it in transit, they see only scrambled nonsense. Only the intended recipient — the server you are connecting to — has the key to unscramble it.
Symmetric Encryption — One Key for Everything
The simplest form of encryption uses a single key to both encrypt and decrypt data.
Think of a padlock with one key. You lock the box with the key, send it to your friend, and she uses the same key to open it. This is symmetric encryption — both sides use the same secret key.
This is fast and efficient, which is why it is used for the bulk of encrypted data transfer. But it has a problem: how do you securely share the key in the first place? You cannot send the key over the internet unencrypted — that defeats the purpose. This is called the key distribution problem.
Modern symmetric encryption uses algorithms like AES (Advanced Encryption Standard) with 256-bit keys. A 256-bit key has 2²⁵⁶ possible values — that is more than the number of atoms in the observable universe. Brute-forcing such a key is computationally impossible with any technology that exists today or is likely to exist.
Asymmetric Encryption — Two Keys
Asymmetric encryption solves the key distribution problem with a clever idea: instead of one key, use two. A public key and a private key. They are mathematically linked but different.
The mailbox analogy works perfectly here:
- Your public key is like a slot in your door. Anyone can push a letter through it. You can share your public key with the whole world.
- Your private key is like the key to your door. Only you have it. Only you can open the door and read the letters inside.
If someone wants to send you an encrypted message, they use your public key to encrypt it. Once encrypted with your public key, it can only be decrypted with your private key — which only you have.
This solves the key distribution problem. You can share your public key openly. There is no secret to distribute.
“Can someone figure out my private key from my public key?”
Not with any computer that exists today. The keys are generated using mathematical problems (like factoring extremely large prime numbers) that are trivially easy in one direction but impossibly hard to reverse. Even with all the computers in the world working together, cracking a modern private key would take longer than the age of the universe.
TLS and HTTPS — Encryption in the Browser
TLS (Transport Layer Security) is the protocol that encrypts web traffic. When you see https:// at the start of a URL, or a padlock in your browser’s address bar, TLS is running underneath.
HTTPS is simply HTTP (the web protocol) running over TLS. It is the standard for all websites that handle any sensitive information — and increasingly for all websites, period.
The TLS Handshake (In Plain English)
When your browser connects to sbi.co.in, a brief but important negotiation happens before any data is exchanged. This is the TLS handshake.
Think of it as two strangers agreeing on a secret language before having a private conversation in a public place:
- Your browser says hello — “I want a secure connection. Here are the encryption methods I support.”
- The server says hello back — “Great. Here is my certificate, proving I am really sbi.co.in. Here is my public key.”
- Your browser verifies the certificate — “Let me check that this certificate is legitimate.” (We cover how in Session 3.)
- They agree on a session key — Using asymmetric encryption, they securely exchange a temporary symmetric key that will be used for the rest of the conversation. (Asymmetric encryption to share a symmetric key — this solves the key distribution problem elegantly.)
- Everything after this is encrypted — All data flows encrypted with the session key. The handshake is complete.
The whole handshake takes milliseconds. You never see it. But every time you connect to a secure site, this happens.
The current standard is TLS 1.3, which is faster and more secure than its predecessors. One improvement: in TLS 1.3, the handshake takes one fewer round trip (message exchange) than TLS 1.2, making connections faster. This matters at scale — Google and Cloudflare were key contributors to the TLS 1.3 specification.
Putting It Together
Encryption did not exist so that criminals could hide ransomware. It exists because the internet is a public infrastructure — packets travel through routers you do not own, networks you do not control, and infrastructure operated by strangers. Without encryption, every sensitive thing you do online — bank transfers, messages, health queries, logins — would be readable by anyone with the right position in the network.
Rajan bhaiya’s story is not about encryption failing. Encryption was working perfectly — the ransomware used it against him. His story is about what happens when you trust without verifying. Session 3 is about how trust works on the internet.