What encryption buys you

Lesson 6-2 covered what risk the Secure attribute prevents.

The session ID crossing the network as readable text, where anyone in the middle could copy it.

Over plain HTTP, headers travel as readable text, and lesson 6-2 showed the session ID is a claim ticket for your whole account. Secure keeps the ticket off unencrypted connections entirely.

This unit explains what HTTPS actually does to make a connection safe, and why "readable text" is the default that had to be fixed.

Who can read your traffic?

Every request you send crosses machines you do not control: the coffee-shop Wi-Fi router, your ISP, a dozen internet routers. With plain http://, all of them see your traffic exactly as you learned to read it in unit 4: the path, the headers, the cookies, the body with your password in it. Readable text, hop after hop.

TLS (Transport Layer Security) fixes this. HTTPS is just HTTP sent through a TLS-encrypted connection, and it buys you three distinct guarantees:

1. Confidentiality: the traffic is encrypted, middlemen see only scrambled bytes.
2. Integrity: if anyone tampers with a message in transit, the receiver detects it and rejects it.
3. Authentication: you are cryptographically sure you are talking to the real yourbank.com, not an impostor (next lesson).

Encryption itself is an old idea: transform the message with a secret key so that only someone with the key can transform it back. Let's build the world's simplest version to feel the mechanics.

A toy cipher

Shift every character's code up by a secret key to encrypt, and down by the same key to decrypt.

key = 7

message = "MEET AT NOON"
encrypted = "".join(chr(ord(c) + key) for c in message)
decrypted = "".join(chr(ord(c) - key) for c in encrypted)

print("plain:     ", message)
print("encrypted: ", encrypted)
print("decrypted: ", decrypted)

Output

plain:      MEET AT NOON
encrypted:  TLL['H['UVVU
decrypted:  MEET AT NOON

Both sides must know the same key. Real TLS uses vastly stronger math, but the shape is the same: the same key in, the same message out.

ord gives a character's number and chr turns a number back into a character, so the whole cipher is arithmetic on those numbers. The space became ' because a space is code 32 and 32 plus 7 is 39.

The weakness is visible in the output if you look. Repeated letters encrypt to repeated symbols, so the double OO in NOON stayed a double VV, which is exactly the pattern that makes such ciphers trivial to break.

Decrypting with the shared key

Undo the shift by subtracting the same key.

key = 7
intercepted = "ZLUK'<7'JVPUZ'[V'HKH"

decrypted = "".join(chr(ord(c) - key) for c in intercepted)
print(decrypted)

Output

SEND 50 COINS TO ADA

Reading the code

• Encryption added the key to each character code, so decryption subtracts it. The two operations are exact inverses, which is what makes the message recoverable.
• "".join(chr(ord(c) - key) for c in intercepted) rebuilds the whole string in one pass, joining with an empty string so no separators appear.
• The same key served both directions, which is the defining property of symmetric encryption and the reason the next block has a problem to solve.
• Note that digits shifted too, so 50 was encrypted as <7. The cipher does not care what the characters mean, which is also true of real encryption: it operates on bytes, not on words.

The key exchange problem

Our toy cipher has a fatal flaw shared by all symmetric encryption: both sides need the same key, but you and yourbank.com have never met. If the server just sent you the key, every middleman would see it too, and the encryption would protect nothing.

The TLS handshake solves this. Right after the TCP handshake from lesson 3-2, the browser and server exchange a few special messages that use asymmetric cryptography, math with a public key that anyone may see and a private key only the server holds, to agree on a fresh shared secret that eavesdroppers watching every message still cannot compute. From then on, everything is encrypted with that shared secret.

You saw this happen in lesson 5-1 without noticing: curl's -v output printed SSL connection using TLSv1.3 between the TCP connect and the first HTTP line. That line is the handshake completing.

What is still visible over HTTPS

A nosy Wi-Fi operator can still see which domain you connected to, and roughly how much data flowed.

TLS encrypts the entire HTTP message, including the path, the headers, the cookies, and the body. None of unit 4's anatomy is readable on the wire.

The connection itself is not hidden though. The server's IP address is necessarily visible, since routers need it to deliver packets, and the domain name is typically sent during the handshake so a server hosting many sites knows which certificate to present.

Traffic volume and timing leak as well. An observer who sees a large download at a particular moment can often guess a great deal without decrypting anything.

The short version is that HTTPS hides what you say, not who you are talking to.