When a Tiffin customer pays for dinner, their request crosses a home router, an ISP, maybe a few backbone networks, and a cloud provider's load balancer. Any of those could, in principle, read or change the bytes. Without protection, anyone on the café Wi-Fi could read the customer's session token, or change the delivery address on the way.
TLS (Transport Layer Security) is what stops that. HTTPS is simply HTTP sent inside a TLS connection. This lesson covers what TLS actually promises, how the TLS 1.3 handshake works, what it costs in round trips and CPU, and where TLS starts and ends in a real system.
Quick recap. Before TLS can start, the client has already looked up the server's address (DNS) and opened a TCP connection, which costs one round trip (RTT). With HTTP/3, TLS is built into QUIC instead. Both are covered earlier in this module.
Three promises
TLS gives two parties a channel where nobody in between can read the data, change it without being noticed, or pretend to be the server.
That's three separate guarantees:
| Guarantee | What it means | What it stops |
|---|---|---|
| Confidentiality | Data is encrypted | The café Wi-Fi reading card details or tokens |
| Integrity | Every record carries a tag that detects tampering | An ISP injecting ads or changing an address |
| Authentication | The server proves it owns the name | A fake api.tiffin.app collecting passwords |
People often remember the first and forget the third. Encryption with the wrong party is worthless. If the Tiffin app happily set up an encrypted channel with an attacker pretending to be api.tiffin.app, the attacker would read everything. Authentication is what certificates are for.