HTTPS and SSL/TLS: Secure Communication

Suppose you are booking a Tatkal train ticket on IRCTC from your phone, connected to your hostel's shared Wi-Fi. At the payment step you type your UPI PIN. Somewhere between your phone and IRCTC's server, that PIN travels as a stream of data packets — hopping through your Wi-Fi router, your ISP's network, and several other machines you will never see. Anyone with access to those intermediate points, and the right free software, can potentially look inside those packets. The question this chapter answers is precise and important: what stops them from reading your PIN, and what stops them from silently changing the amount from ₹500 to ₹50,000 while the packet is in transit? The answer is a protocol most of you have already used a thousand times without knowing its name: TLS, wrapped around HTTP to make HTTPS.

Plaintext on a Postcard: What Plain HTTP Actually Sends

Before TLS existed, websites communicated using plain HTTP, and HTTP sends everything as readable text — literally the same ASCII characters you would type into a text editor. When you submit a login form over plain HTTP, the browser builds a request that looks roughly like this and sends it exactly as shown, byte for byte, across the network:

POST /login HTTP/1.1
Host: www.examschoolportal.in
Content-Type: application/x-www-form-urlencoded
Content-Length: 39

username=rahul_2010&password=Cricket@99

Notice that the password is not hidden in any way — it is sitting in the request body as plain text, exactly as typed. Anyone who can intercept this packet, whether that is a person running packet-capture software on the same public Wi-Fi, a malicious router along the path, or your ISP, can simply read password=Cricket@99 off the wire. This is why plain HTTP is often compared to writing a message on a postcard: it travels through many hands on its way to the destination, and every one of those hands can read it without breaking anything open. HTTPS exists to turn that postcard into a sealed, tamper-evident envelope that only the intended recipient can open — and that can prove, if opened early, that it was opened.

Three Separate Guarantees Hiding Inside the Word "Secure"

Students often treat "HTTPS is secure" as one vague property. It is actually three distinct, precisely defined guarantees, and a good security protocol has to deliver all three at once:

• Confidentiality — no one except the sender and the intended receiver can read the content. Your UPI PIN stays unreadable to anyone snooping on the network.
• Integrity — if even a single bit of the message is altered in transit, the receiver can detect it. An attacker cannot quietly change ₹500 to ₹50,000 without the tampering being noticed.
• Authentication — the receiver can confirm it is really talking to the server it thinks it is talking to (irctc.co.in, and not an impostor pretending to be irctc.co.in).

HTTP by itself provides none of these. HTTPS provides all three, by running ordinary HTTP on top of a security layer called TLS (Transport Layer Security — SSL is its older name, explained later in this chapter). To understand how TLS delivers these three guarantees, we need to build up the cryptography piece by piece, starting from the simplest possible idea: locking a message with a shared key.

Symmetric Encryption: One Key Locks and Unlocks

The simplest way to hide a message is to scramble it with a secret key that both the sender and receiver know, and use the exact same key to unscramble it. This is called symmetric-key encryption — "symmetric" because the same key works in both directions, exactly like a physical padlock where one key both locks and opens it.

Here is a genuinely simple, working symmetric cipher you can trace by hand: the XOR cipher. It combines each character of the message with a character of the key using the bitwise XOR operation, which has one very useful property — applying the same XOR twice cancels out and returns the original value, because for any bits a and b, a XOR b XOR b = a.

def xor_cipher(text, key):
    result = ""
    for i in range(len(text)):
        result += chr(ord(text[i]) ^ ord(key[i % len(key)]))
    return result

message = "HI"
key = "K"

encrypted = xor_cipher(message, key)
decrypted = xor_cipher(encrypted, key)

print(decrypted)

Trace it by hand using ASCII codes. ord('H') = 72, which is 01001000 in binary, and ord('K') = 75, which is 01001011. XOR-ing them bit by bit:

  01001000   (H = 72)
^ 01001011   (K = 75)
-----------
  00000011   (3, an unprintable control character)

For the second character, ord('I') = 73 (01001001), XORed again with 75 (01001011) gives 00000010, which is 2. So encrypted is the two-character string made of ASCII codes 3 and 2 — neither is a printable letter, which is exactly what we want from a cipher: the scrambled output should look nothing like the input. Now watch what happens when we run xor_cipher a second time on that encrypted string, using the same key "K": 3 XOR 75 = 72 (back to 'H'), and 2 XOR 75 = 73 (back to 'I'). So decrypted is exactly "HI" again, and print(decrypted) outputs HI. The same key that scrambled the message also unscrambles it — that is the defining feature of symmetric encryption.

Real TLS connections do not use plain XOR — it is trivially breakable by an attacker who knows or guesses even a fragment of the plaintext, because XOR-ing the ciphertext with a guessed plaintext instantly reveals key bytes. Modern TLS uses a much stronger symmetric cipher called AES (Advanced Encryption Standard), typically with a 256-bit key, combined with an integrity check. But the core principle — one shared key encrypts and decrypts, and it is fast enough to run on every byte of a video call or a UPI transaction — is exactly what the XOR example demonstrates. Integrity, the second guarantee from the previous section, is added alongside the cipher: TLS computes a short tag from the message and the key (called a MAC, or Message Authentication Code) and sends it along with the ciphertext; changing even one bit of the encrypted message makes the tag fail to match when the receiver recomputes it, exposing the tampering.

The Real Problem: Two Strangers, One Insecure Line

Symmetric encryption is fast and effective once both sides share a secret key. But your browser has never met irctc.co.in's server before this exact connection. There is no courier who can hand-deliver a secret key beforehand. And the only channel available to agree on a key is the same public, snoopable internet the attacker is already watching. If your browser simply sent the key in the clear so the server could use it, the attacker watching the network would see the key too, and the entire scheme would be worthless. This is the key-distribution problem, and it stumped cryptographers for decades until 1976, when Whitfield Diffie and Martin Hellman published a method that solves it using nothing but modular arithmetic.

The intuition is usually explained with paint. Imagine Alice and Bob each start with a can of yellow paint, publicly agreed on (anyone watching can know it is yellow). Alice privately mixes in her own secret color, and Bob privately mixes in his own secret color. They swap their mixed cans in public — the attacker sees both mixtures, but mixed paint cannot be un-mixed back into its ingredients. Now each of them adds their own secret color a second time, into the can they just received. Alice ends up with yellow + her secret + Bob's secret; Bob ends up with yellow + Bob's secret + Alice's secret — the same final color, even though neither ever sent their own secret color across the public channel, and even though an eavesdropper saw every publicly exchanged can.

Diffie–Hellman key exchange does exactly this with numbers instead of paint, using modular exponentiation (the "paint" is not mixed, but raised to a power and reduced modulo a large prime — an operation that is easy to compute forward but very hard to reverse). Here is a worked example with small numbers so you can check every step by hand — real TLS connections use numbers hundreds of digits long, but the arithmetic is identical in principle.

Both sides publicly agree on a prime p = 23 and a base g = 5 (an eavesdropper is allowed to know both). Alice privately picks a secret number a = 6 and Bob privately picks a secret number b = 15 — these secrets never leave their own machines.

Alice computes: A = g^a mod p = 5^6 mod 23
  5^2 mod 23 = 25 mod 23 = 2
  5^4 mod 23 = 2^2       = 4
  5^6 mod 23 = 5^4 * 5^2 = 4 * 2 = 8
  A = 8   (Alice sends this number publicly)

Bob computes: B = g^b mod p = 5^15 mod 23
  5^1 = 5,  5^2 = 2,  5^4 = 4,  5^8 = 4^2 = 16
  5^15 = 5^8 * 5^4 * 5^2 * 5^1 mod 23
       = 16 * 4 * 2 * 5 mod 23
       = 18 * 2 * 5 mod 23      (16*4 = 64 mod 23 = 18)
       = 13 * 5 mod 23          (18*2 = 36 mod 23 = 13)
       = 19                     (13*5 = 65 mod 23 = 19)
  B = 19   (Bob sends this number publicly)

Now the crucial step: Alice takes Bob's public number B = 19 and raises it to her own private exponent a = 6; Bob takes Alice's public number A = 8 and raises it to his own private exponent b = 15.

Alice: B^a mod p = 19^6 mod 23
  19^2 mod 23 = 361 mod 23 = 16
  19^4 mod 23 = 16^2 mod 23 = 256 mod 23 = 3
  19^6 mod 23 = 19^4 * 19^2 = 3 * 16 mod 23 = 48 mod 23 = 2

Bob: A^b mod p = 8^15 mod 23
  8^2=64mod23=18, 8^4=18^2 mod23=324mod23=2, 8^8=2^2=4
  8^15 = 8^8 * 8^4 * 8^2 * 8^1 mod 23
       = 4 * 2 * 18 * 8 mod 23
       = 8 * 18 * 8 mod 23        (4*2=8)
       = 6 * 8 mod 23             (8*18=144 mod 23 = 6)
       = 2                        (6*8=48 mod 23 = 2)

Both arrive independently at 2. That shared number, 2, becomes the symmetric key both sides now feed into AES for the rest of the conversation — computed without ever transmitting either private number. An eavesdropper who recorded p = 23, g = 5, A = 8, and B = 19 still cannot recover the shared key without solving for Alice's private exponent a from 5^a mod 23 = 8 — a problem called the discrete logarithm problem. For our tiny prime 23, that is fast to brute-force by hand. But the primes real TLS connections use are typically 2048 bits long — numbers with over 600 decimal digits. Computing forward (exponentiation) stays fast at that size; reversing it (the discrete logarithm) is believed to take longer than the age of the universe with any known algorithm and today's computers. That asymmetry between "easy forward, hard in reverse" is the mathematical foundation the entire scheme rests on.

A Second Kind of Lock: Public-Key Cryptography and Certificates

Diffie–Hellman solves the key-exchange problem, but it leaves one gap: it proves both parties end up with the same secret number, but not who the other party actually is. An attacker sitting in the middle of the connection could run the exact same exchange twice — once pretending to be the server while talking to you, and once pretending to be you while talking to the real server — relaying and reading everything in between. This is called a man-in-the-middle attack, and defeating it needs the third guarantee from earlier: authentication.

Authentication in TLS is handled by a second, different kind of cryptography: asymmetric (public-key) cryptography, most commonly RSA. Unlike a symmetric cipher, an asymmetric system generates a mathematically linked pair of keys — a public key that can be freely shared with anyone, and a private key that never leaves the owner's server. Data locked with the public key can only be unlocked with the matching private key, and — crucially for authentication — data signed with the private key can be verified by anyone using the public key, proving it came from whoever holds that private key. RSA's security rests on a different hard problem than Diffie–Hellman's: multiplying two large prime numbers together is fast, but factoring the product back into its two original primes is extremely slow once the primes are large. You can check this yourself with small numbers: computing 7 × 13 = 91 takes a second, but if someone hands you only 91 and asks for its two prime factors, you have to search — and for a 2048-bit RSA modulus, that search is computationally infeasible with current technology.

Here is how this solves the identity problem. A website like irctc.co.in generates a key pair and gets its public key bundled into a digital certificate — a file that states "this public key belongs to irctc.co.in" — signed by a trusted third party called a Certificate Authority (CA). Your browser ships with a pre-installed list of CAs it trusts (global CAs such as DigiCert and the nonprofit Let's Encrypt, alongside CAs licensed under India's IT Act such as eMudhra, whose root certificates are recognised by major browsers). When irctc.co.in's server presents its certificate during connection setup, your browser checks the CA's signature on it using the CA's own public key, which it already trusts. If the signature checks out, and the domain name inside the certificate matches the address bar, the browser accepts that the public key genuinely belongs to IRCTC — closing the man-in-the-middle gap that Diffie–Hellman alone could not close. This chain of trust — CA vouches for server, browser vouches for CA — is why a valid certificate is often compared to a passport: it is only useful because it was issued and signed by an authority you already trust, not because of anything the holder says about themselves.

Putting It All Together: The TLS Handshake

Every piece above — symmetric encryption for speed, Diffie–Hellman for key exchange, RSA-signed certificates for identity — is assembled into a single sequence of messages called the TLS handshake, which runs automatically before your browser exchanges a single byte of the actual webpage. The diagram below traces the sequence for the modern standard, TLS 1.3.

Two details in this sequence are worth naming explicitly, because they explain why TLS is built as a two-stage system rather than using RSA for everything. First, asymmetric operations like RSA verification are computationally expensive — orders of magnitude slower than symmetric AES operations — so TLS uses them sparingly, only during the brief handshake, to establish trust and agree on a key. Second, once the shared session key exists, all the actual data (the webpage, the images, your UPI PIN, IRCTC's confirmation) travels using fast symmetric AES encryption, the same principle you traced by hand in the XOR example earlier. TLS 1.3, the current version, streamlined this handshake down to a single round trip (the client can send its DH value in the very first message, as shown in step 1 above), compared to two round trips in the older TLS 1.2 — a real, measurable reason pages load faster on modern TLS.

SSL and TLS: Same Job, Different Names, Different Safety

The letters "SSL" still appear everywhere — "SSL certificate," "SSL padlock" — even though no website you use today actually runs the SSL protocol. Here is the real history. SSL (Secure Sockets Layer) was created by Netscape in the mid-1990s. SSL 2.0 (1995) shipped with serious design flaws and was formally prohibited for use in 2011. SSL 3.0 (1996) fixed some of those flaws but was itself broken by the POODLE attack discovered in 2014, and formally deprecated in 2015. The protocol was then handed to the Internet Engineering Task Force, which renamed it TLS (Transport Layer Security) and released TLS 1.0 in 1999, followed by TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3 (2018), each fixing weaknesses found in its predecessor. Every browser released in the last several years refuses to connect using SSL 2.0, SSL 3.0, or even the older TLS 1.0/1.1 versions on sites that require higher security, and negotiates TLS 1.2 or TLS 1.3 instead. So when someone says "SSL certificate" today, what actually protects the connection is TLS — the name "SSL" survives purely as an older, informal habit of speech, not because the SSL protocol itself is still in use.

HTTPS: HTTP Riding on Top of TLS

HTTPS is not a separate protocol invented from scratch — it is exactly the same HTTP you already know (the same GET and POST requests, the same headers), except the entire connection first passes through the TLS handshake described above, and every byte of the HTTP conversation is then encrypted before it touches the network. This has two visible consequences you can check on any website: the URL scheme changes from http:// to https://, and the default network port changes from port 80 (plain HTTP) to port 443 (HTTPS). The padlock icon your browser shows in the address bar is simply a signal that the TLS handshake completed successfully and the certificate check passed.

Common Misconception: "The Padlock Means the Site Is Safe"

This is one of the most common and most dangerous misunderstandings about HTTPS, worth correcting explicitly. The padlock icon guarantees exactly two things: the connection is encrypted (nobody can read the traffic in transit), and the certificate's domain name matches the site you are visiting. It guarantees nothing whatsoever about whether the organization running that site is honest, legitimate, or safe to give money to. Certificate Authorities such as Let's Encrypt issue certificates automatically, for free, to any domain name that can prove it controls that domain — with no check on who registered the domain or what they intend to do with it. An attacker can freely register a lookalike domain such as sbi-secure-login.com or irctc-refund-claim.in, obtain a completely valid HTTPS certificate for it in minutes, and present a fully padlocked page to phishing victims. The padlock on that page is not lying — the connection genuinely is encrypted — but encryption protects data in transit, not the trustworthiness of who is receiving it. The correct habit is to read the actual domain name in the address bar character by character, not just glance for the padlock icon.

Check Yourself

1. In plain HTTP, why can an attacker on the same Wi-Fi network read your submitted password without needing to "hack" anything?
2. Name the three guarantees "secure communication" must provide, and give one everyday example of each being violated.
3. In the XOR trace, why does running xor_cipher a second time with the same key return the original message? State the property of XOR responsible.
4. Diffie–Hellman practice: with p = 13, g = 6, Alice's private value a = 3, and Bob's private value b = 5, compute Alice's public value A, Bob's public value B, and verify both sides arrive at the same shared secret.
5. Why does TLS use slow asymmetric cryptography only briefly during the handshake, and fast symmetric cryptography for the actual data?
6. What exactly does the browser's padlock icon guarantee, and what does it not guarantee? Give a concrete phishing scenario where the padlock is present but the site is still dangerous.
7. Is "SSL" the protocol actually protecting your connection to a modern website? Explain what changed and why the name persists in everyday speech.

Worked answer to Question 4: A = 6^3 mod 13. Since 6^2 = 36 mod 13 = 10, 6^3 = 10 × 6 = 60 mod 13 = 8, so A = 8. B = 6^5 mod 13: 6^4 = 10^2 mod 13 = 100 mod 13 = 9, so 6^5 = 9 × 6 = 54 mod 13 = 2, giving B = 2. Alice computes the shared secret as B^a mod p = 2^3 mod 13 = 8. Bob computes it as A^b mod p = 8^5 mod 13: 8^2 = 64 mod 13 = 12, 8^4 = 12^2 mod 13 = 144 mod 13 = 1, so 8^5 = 1 × 8 = 8. Both sides reach 8 — the shared session key.

Summary

• Plain HTTP sends every byte, including passwords, as readable text — like writing on a postcard. HTTPS wraps HTTP inside TLS, a protocol that provides confidentiality, integrity, and authentication.
• Symmetric encryption (illustrated with the XOR cipher, used for real with AES in TLS) uses one shared key to both encrypt and decrypt, and is fast enough for bulk data — but requires both sides to already possess the same secret key.
• Diffie–Hellman key exchange lets two strangers on an insecure channel agree on a shared secret using modular exponentiation, without ever transmitting the secret itself — protected by the difficulty of the discrete logarithm problem for large primes.
• Asymmetric (public-key) cryptography, typically RSA, provides authentication: a Certificate Authority signs a server's public key into a digital certificate, and the browser's pre-installed trust in that CA lets it confirm the server's identity, closing the man-in-the-middle gap that key exchange alone leaves open.
• The TLS handshake combines all of this: negotiate parameters, exchange and verify the certificate, derive a shared session key, then switch to fast symmetric encryption for the actual application data.
• "SSL" is the deprecated ancestor protocol; "TLS" is what actually protects modern connections. The name "SSL" survives only as an informal habit of speech.
• The padlock icon proves an encrypted, identity-checked connection to whatever domain is in the address bar — it proves nothing about whether that domain is trustworthy. Always read the domain name itself.