What TLS protects — and what it does not

TLS (Transport Layer Security) sits between TCP and your application. It takes a stream of bytes, wraps it in encryption and authentication, and hands it back. The older name SSL is still used out of habit; the SSL protocol versions themselves are dead.

• It does not authorise the client. Authenticating a user is the application's job (mutual TLS changes the authentication, not the authorisation)
• It does not protect data once the application has it — logging, backups and plugins are out of scope
• It does not hide all metadata: the server name (SNI), IP addresses and packet timing are usually visible
• It does not make a website trustworthy. A padlock means the connection is encrypted to the named host
• It does not survive a compromised endpoint: if malware runs on the client, TLS is irrelevant

Students frequently assume HTTPS equals 'safe'. A sharper statement: HTTPS means the bytes between the application and the server are private and unmodified, and the server proved it holds the key for the requested name.

Application      HTTP/2, HTTP/3, SMTP, IMAP, LDAP ...
TLS 1.3/1.2      handshake, encryption, authentication
TCP (or QUIC)    ordered bytes, or QUIC's encrypted transport
IP               addressing and routing

HTTP/3 replaces TCP with QUIC, which builds TLS 1.3 into the transport. The cryptographic ideas are identical; the plumbing moves. Everything you learn in this course applies to both.

During the handshake the client says which hostname it wants (Server Name Indication, SNI) so the server can pick the right certificate. On traditional TLS this is sent in clear, so an observer learns which sites you visit, even though not what you read.

Encrypted Client Hello (ECH) hides the SNI by encrypting it to a key published in DNS. It is deployed in some browsers today. It reduces, but does not eliminate, traffic analysis: IP addresses remain visible.