What is TLS (SSL)?
Definition
TLS (Transport Layer Security) is the cryptographic protocol that protects a connection between two applications against eavesdropping, tampering and forged messages. HTTPS, secure email transport and most API traffic run on top of it. The name SSL, still widely used, comes from TLS's predecessor, which is now considered insecure. The versions that should be enabled today are TLS 1.2 and TLS 1.3.
Also known as: Transport Layer Security, SSL, Secure Sockets Layer, TLS 1.3, TLS 1.2, SSL/TLS
From SSL to TLS: a naming history
SSL (Secure Sockets Layer) was developed by Netscape in the mid-1990s and became the first widely used protocol for encrypting web traffic. When the IETF took it over, it was renamed: TLS 1.0 appeared in 1999 as the successor to SSL 3.0. SSL 2.0 and 3.0 were formally deprecated years ago after serious weaknesses were found, and RFC 8996 deprecated TLS 1.0 and 1.1 in March 2021. So when someone says "SSL" today they almost always mean TLS, and an "SSL certificate" is simply a certificate used with TLS.
| Version | Year | Status |
|---|---|---|
| SSL 2.0 / 3.0 | 1995 / 1996 | Deprecated; disable |
| TLS 1.0 / 1.1 | 1999 / 2006 | Deprecated in 2021; disable |
| TLS 1.2 | 2008 | Still common; acceptable with strong cipher suites |
| TLS 1.3 | 2018 | Current version; prefer it |
The handshake, conceptually
Before any application data flows, client and server have to settle three things: which algorithms to use, whether the server is who it claims to be, and which secret keys will protect the session. In TLS 1.3 the exchange looks roughly like this:
- The client sends a "ClientHello" listing the versions and cipher suites it supports, plus its share of a key agreement.
- The server picks the parameters, adds its own key share and sends its SSL/TLS certificate, then signs the handshake to prove it holds the private key matching the certificate.
- The client validates the certificate chain up to a root it trusts and checks that the hostname matches.
- Both sides independently derive the same session keys from the exchanged values. Those keys never cross the network.
From then on, data is protected with fast symmetric encryption such as AES-GCM or ChaCha20-Poly1305. Public-key cryptography is used only for authentication and key agreement, because it is far too slow for bulk data.
What TLS 1.3 changed
- A faster handshake: a fresh connection needs one round trip instead of the two required by TLS 1.2. When resuming with a known server, optional 0-RTT lets the client send data with its very first flight, but that early data can be replayed, so it should only carry requests that are safe to repeat.
- Forward secrecy by default: static RSA key exchange is gone. Even if the server's private key leaks later, previously recorded traffic stays unreadable.
- Fewer knobs to get wrong: RC4 and older modes without authenticated encryption were removed; only AEAD ciphers remain.
- More privacy: the server certificate is now sent inside the encrypted part of the handshake.
QUIC, the transport under HTTP/3, builds TLS 1.3 directly into the protocol. The full specification is RFC 8446.
Sensible server configuration
Enable TLS 1.2 and 1.3 only; switching off older versions now affects only very old clients. For TLS 1.2, choose suites with ECDHE key exchange and AEAD ciphers. Monitor certificate expiry and make sure the server sends the full chain, since a missing intermediate certificate is one of the most common causes of "untrusted connection" errors on some clients. And keep the scope in mind: TLS protects the connection, not the application. A malicious request delivered over a perfectly encrypted channel still reaches your code.