TLS: Encryption, Integrity and Identity

TLS (Transport Layer Security) protects a connection with three guarantees: encryption, so nobody on the path can read what is sent; integrity, so any change in transit is detected; and authentication, so the client knows which server it is talking to. HTTPS is ordinary HTTP sent inside a TLS connection, and the same protection carries email, database connections and most other traffic.

Picture a laptop on café Wi-Fi logging in to a shop. Without TLS, anyone on that network can read the request, password included, or change the reply. With TLS, they see that a connection exists and nothing of what it carries.

Each guarantee answers a different attack.

Encryption stops eavesdropping. The two ends agree on keys that nobody watching can work out, and use them to scramble everything they send.

Integrity stops tampering. Every record carries a check computed with the shared key, so a changed byte makes the record fail and the connection end.

Authentication stops impersonation. Encryption with the wrong server would be worthless, so the server proves its identity with a certificate, a signed document binding its name to a public key, which the client checks before trusting anything.

What TLS does not hide matters as much. The IP addresses and ports are in the IP and TCP headers, outside TLS. The size and timing of messages are visible, and can reveal a surprising amount. The host name usually travels in readable form at the start of the handshake. And TLS protects data only in transit: once it arrives, the server sees all of it.

So when someone asks what HTTPS protects, the answer is the content of the conversation, not the fact that it happened or who it was with.