Cloud Parts

TLS

Transport Layer Security: a handshake that authenticates the server (and optionally the client) and agrees on fresh keys, then records that keep everything above it private and tamper-evident.

What it is
Network protocols (security protocols)
Type
Open source
Made by
IETF
License
Open standard (IETF RFC)
Facts checked
8 October 2026
Website

What it is

TLS needs only a reliable, in-order stream underneath, usually TCP, and is independent of the application on top. It has two parts. The handshake authenticates the peers, negotiates algorithms and establishes shared keys; the record protocol then splits traffic into records, each encrypted and authenticated with those keys. In TLS 1.3 the client’s first message, the ClientHello, already carries its key share and the versions and ciphers it supports. The server answers with its own share in ServerHello, and from then on everything is encrypted: its extensions, its certificate, a signature over the whole handshake (CertificateVerify) and a Finished MAC. The client checks that the certificate is valid for the host it asked for, sends its own Finished, and application data flows. A full handshake costs one round trip; a client resuming an earlier session can send early data in its first flight (0-RTT), which has weaker guarantees: it can be replayed and isn’t forward secret.

Extensions do much of the practical work. Server Name Indication (server_name) tells the server which host the client wants, so one IP address can serve many certificates, and ALPN lets the two sides agree on h2 or http/1.1 during the handshake. TLS 1.3 was first published as RFC 8446 in August 2018 and republished, with corrections and clarifications, as RFC 9846 in July 2026, which also obsoletes the TLS 1.2 specification. Implementations include OpenSSL, which supports TLS 1.2 and 1.3 by default, and the same protocol secures HTTPS, FTPS and mail; QUIC uses its handshake to set up its own encryption.

Why teams pick it

  • Works under almost any application protocol unchanged: HTTPS is HTTP sent as TLS application data
  • TLS 1.3 keeps only AEAD ciphers and removes static RSA, so every public-key key exchange has forward secrecy
  • Encrypts the handshake after ServerHello, including the server’s certificate, and needs just one round trip to set up
  • Certificates can be issued and renewed automatically: ACME (RFC 8555) is a standard protocol for proving control of a domain to a certificate authority

Watch out for

  • The ClientHello, with the server name the client asks for, is sent before any keys exist, so an observer can still see which site you’re connecting to
  • TLS doesn’t hide how much data is sent; endpoints can pad records, but by default lengths leak
  • Certificates have to be issued, deployed and renewed; when one expires or doesn’t match the host name, clients that verify must refuse or ask the user
  • 0-RTT early data can be replayed by an attacker, so applications must only accept requests in it that are safe to process twice

How it fits with other technologies

Look at a server’s TLS handshake with OpenSSL · bash

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_256_GCM_SHA384
# Peer certificate: CN=example.com
# Verification: OK
# (exact lines vary with the OpenSSL version and the server)

See it in a real stack

No architecture uses TLS yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1995–2026

HTTP was originally used in the clear, and Netscape built the Secure Sockets Layer to protect it. SSL 2.0 was specified by Kipp Hickman in February 1995 and replaced by SSL 3.0, whose November 1996 version became the basis of the IETF’s TLS 1.0 (RFC 2246, January 1999). The differences were small but enough that TLS 1.0 and SSL 3.0 don’t interoperate. SSL 3.0 itself only became an RFC in 2011, as a historical record (RFC 6101).

TLS 1.1 followed in April 2006 and TLS 1.2 in August 2008, which became the recommended version for IETF protocols for the next decade. TLS 1.3 (RFC 8446, August 2018), written by Eric Rescorla, co-author of 1.1 and 1.2, was a deeper redesign: it pruned every cipher that isn’t AEAD, dropped static RSA and Diffie-Hellman so public-key exchanges always have forward secrecy, encrypted the handshake after ServerHello, added 0-RTT and redesigned key derivation around HKDF. The IETF prohibited SSL 3.0 in 2015 and deprecated TLS 1.0 and 1.1 in March 2021. In July 2026 it republished TLS 1.3 as RFC 9846, which obsoletes both RFC 8446 and the TLS 1.2 specification and adds requirements for TLS 1.2 implementations.

Why it’s built this way

A layer under the application, not part of it
TLS only assumes a reliable stream and lets higher-level protocols layer on top transparently. So securing HTTP meant running it over TLS “precisely as you would use HTTP over TCP” (RFC 2818), and FTP and mail could do the same.
Always authenticate the server, optionally the client
The client must know it reached the real site before it sends secrets, so the server always proves its identity, usually with a certificate. Client certificates are optional, for cases such as mutual TLS between services.
Fewer options in TLS 1.3
TLS 1.3 removed legacy ciphers, static RSA and DH, compression and custom DHE groups, leaving a smaller set of choices that all provide forward secrecy and are easier to analyse.
Offer 0-RTT, with a warning
Saving a round trip on resumption makes repeat connections faster, so TLS 1.3 allows early data, but the specification spells out that it can be replayed and isn’t forward secret.

Timeline

  1. 1995

    Netscape’s SSL 2.0 specification (Kipp Hickman, February)

  2. 1996

    SSL 3.0, the version TLS is based on (November 18)

  3. 1999

    TLS 1.0 published as RFC 2246

  4. 2008

    TLS 1.2 (RFC 5246) becomes the recommended version

  5. 2018

    TLS 1.3 published as RFC 8446

  6. 2021

    TLS 1.0 and 1.1 formally deprecated (RFC 8996)

  7. 2026

    TLS 1.3 republished as RFC 9846, obsoleting RFC 8446 and RFC 5246

Sources9 · facts checked 8 October 2026

Improve this page on GitHub