Concepts: Encryption & TLS

Why Plain HTTP Is a Problem

When Deepa logs in at the café, her request travels through several networks before reaching the server. On an unencrypted HTTP connection, every device on that path — every router, every switch, every device on the same Wi-Fi network — can read the contents of her request in plain text.

This is not a theoretical risk. It is how HTTP was designed — as an open, readable protocol. The data flowing through it looks like this to any device on the path:

POST /login HTTP/1.1
Host: example.com

[email protected]&password=mypassword123

Anyone with access to the network traffic can read that. Not just the username and password — everything:

• The exact page she is viewing
• The content of every form she fills in
• Every article she reads
• Every search she makes
• Her session cookies

The postcard analogy: sending data over HTTP is like writing a message on a postcard and dropping it in a letterbox. Every postal worker who handles it can read the front and back. The data arrives at its destination — but it was readable the entire journey.

The Answer: Encryption

Encryption is the transformation of readable data (called plaintext) into unreadable scrambled data (called ciphertext) that can only be unscrambled by someone with the correct key.

When Deepa’s browser sends data over HTTPS, the data is encrypted before it leaves her device. Every router on the path sees only ciphertext — scrambled nonsense. Only the server she is connecting to holds the key to decrypt it.

The sealed letter: HTTPS is like putting that postcard inside a locked box. The postal workers still handle it. They still deliver it. But they cannot read what is inside.

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.

Plaintext → [ Encrypt with Key ] → Ciphertext → [ Decrypt with Key ] → Plaintext

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.

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.

Anyone  → [ Encrypt with Public Key ] → Ciphertext
                                             ↓
                              [ Decrypt with Private Key ] → Plaintext (only you)

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.

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 a secure site, 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:

Browser                                     Server
   │                                           │
   │──── "Hello, I support TLS 1.3" ─────────►│
   │                                           │
   │◄─── Certificate + Public Key ────────────│
   │                                           │
   │  (Browser verifies certificate —          │
   │   see Session 3 for how)                  │
   │                                           │
   │──── Encrypted session key ──────────────►│
   │     (using server's public key)           │
   │                                           │
   │◄══════ All data now encrypted ═══════════►│
   │         (using shared session key)        │

1. Your browser says hello — “I want a secure connection. Here are the encryption methods I support.”
2. The server says hello back — “Great. Here is my certificate, proving who I am. Here is my public key.”
3. Your browser verifies the certificate — “Let me check that this certificate is legitimate.” (We cover how in Session 3.)
4. 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.
5. 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.

Putting It Together

Encryption does not exist to hide things from governments or to enable criminals. 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.

The café Wi-Fi story from the opening: with HTTP, every router on the path can read Deepa’s credentials. With HTTPS and TLS, they see only ciphertext. The physical path is the same. The privacy is completely different.