TLS (Transport Layer Security)

TLS is the successor to SSL and sits between TCP and an application protocol such as HTTP, SMTP or IMAP; QUIC reuses the TLS 1.3 handshake. A connection starts with a handshake in which client and server agree on a version and cipher suite, the server proves its identity with an X.509 certificate, and both sides derive shared session keys. Application data is then encrypted and integrity-protected. The versions in use are TLS 1.2 (RFC 5246, 2008) and TLS 1.3 (RFC 8446, August 2018).

Why it matters

TLS protects passwords, cookies and API tokens from eavesdropping and tampering on untrusted networks, and certificate authentication stops an attacker from impersonating the server. Version choices matter: TLS 1.0 and 1.1 were removed from Chrome 84, Edge 84 and Firefox 78 in 2020 and formally deprecated by RFC 8996 in March 2021. TLS 1.3 removed static RSA key exchange and non-AEAD ciphers, so every TLS 1.3 connection has forward secrecy, and a full handshake needs one round trip instead of two.

Example

Check whether a server supports TLS 1.3:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

If it does, the output reports TLSv1.3 and the negotiated cipher suite; a handshake failure means only older versions are offered.

Common misconceptions

• TLS hides which website you visit. The destination IP is visible, and the hostname travels in cleartext in the SNI extension unless Encrypted Client Hello is used.
• A site that uses TLS is trustworthy. TLS only proves you reached the holder of a certificate for that hostname; phishing sites use TLS too.
• TLS 1.2 is insecure. TLS 1.2 limited to ECDHE key exchange and AEAD cipher suites remains widely accepted; the versions to retire are 1.0 and 1.1 and legacy algorithms.