What TLS guarantees

Every time you see https://, TLS (Transport Layer Security) is working. It protects the data you send, it detects anyone who changes it, and it checks that you are talking to the real bank.com and not someone pretending to be it. Before you can debug a broken handshake, you need to know which of these three promises it is making.

The big idea: three guarantees

TLS gives three properties.

• Confidentiality. Only the two ends can read the data. Someone on public Wi-Fi or at an internet provider sees encrypted bytes.
• Integrity. If anyone changes the data in transit, the receiver detects it and drops the connection. Modern TLS uses ciphers, such as AES-GCM and ChaCha20-Poly1305, that encrypt and authenticate each record together.
• Authentication. The client checks the server's identity with a certificate. Optionally, the server checks the client too. That is called mutual TLS, or mTLS.

Encryption alone is not enough. Without authentication, an attacker in the middle can set up one encrypted connection with you and another with the server, and read everything in between. The certificate check is what stops this.

Where TLS sits

TLS runs between TCP and the application. HTTP, SMTP, Postgres and gRPC each hand their plaintext to a TLS library, such as OpenSSL, BoringSSL, rustls or Go's crypto/tls. The library encrypts it into records and writes them to the TCP socket.

application   HTTP request
TLS           encrypts the bytes into records, checks the server's certificate
TCP           delivers the records in order
IP            routes the packets

In HTTP/3, the TLS handshake runs inside QUIC instead of over TCP. See HTTP.

What TLS does not hide

TLS protects the content of the connection, not everything about it.

• IP addresses and ports are visible to anyone on the path.
• The hostname usually is too. The client sends it in the SNI (Server Name Indication) field of the first message, because the server needs it to pick the right certificate. Encrypted Client Hello closes this gap, but as of 2025 to 2026 it is only partly deployed.
• Message sizes and timing are visible. An observer can often guess what kind of traffic it is, even without reading it.

Common mistakes

• Assuming TLS hides who you talk to. The hostname usually leaks through SNI.
• Assuming encryption alone is safe. Without the certificate check, a man in the middle can read everything.
• Turning off verification to make an error go away. That removes the authentication and leaves only the encryption.

Check yourself

1. Which TLS guarantee stops an attacker from reading traffic with their own key? Authentication. The certificate check proves the server's identity, so the attacker cannot set up a connection that looks like the real server.
2. Why can an observer on public Wi-Fi still see which site you visit? The hostname is sent in the SNI field of the first message, which is not encrypted in most deployments.

Key takeaways

• TLS provides confidentiality, integrity and server authentication. Optional mTLS adds client authentication.
• Encryption without authentication does not stop a man in the middle.
• TLS sits between TCP and the application, and it encrypts records.
• The hostname and the traffic pattern usually remain visible.

Further learning

Next, read the hub, TLS and certificates, for the handshake, the certificate chain and what to do when renewals fail. Then read the TLS 1.3 handshake to see how the two ends agree on keys.