TLS

TLS consists of a record protocol, which fragments application data, protects each record with an AEAD cipher and sequence-number-based nonces, and several sub-protocols carried in records: the handshake, alerts and, in older versions, change cipher spec. The lineage runs from Netscape's SSL 2.0 (1995) and SSL 3.0 (1996) through TLS 1.0 (RFC 2246, 1999), 1.1 (RFC 4346, 2006) and 1.2 (RFC 5246, 2008) to TLS 1.3 (RFC 8446, 2018). RFC 8996 (2021) formally deprecated TLS 1.0 and 1.1, and RFC 9325 gives current configuration recommendations. DTLS adapts the same design to UDP; DTLS 1.3 is RFC 9147.

In the TLS 1.3 full handshake (RFC 8446 §2) the client sends a ClientHello with supported cipher suites, a key_share containing one or more ephemeral (EC)DHE public keys, supported_versions and SNI. The server replies with a ServerHello carrying its own key share; from that point both sides derive handshake keys via an HKDF-based key schedule, and the rest of the server's flight - EncryptedExtensions, Certificate, CertificateVerify (a signature over the transcript) and Finished - is already encrypted. The client verifies the chain, sends its Finished message, and application data flows after one round trip. Resumption with a pre-shared key can add 0-RTT early data, which is not protected against replay and must only be used for idempotent requests.

TLS 1.3 removed a long list of legacy features that had been the root of earlier attacks: static RSA key transport (Bleichenbacher-style oracles, ROBOT), CBC-mode ciphers (BEAST, Lucky Thirteen, POODLE against SSL 3.0), RC4, compression (CRIME), renegotiation and export-grade and custom Diffie-Hellman groups (FREAK, Logjam). Only five cipher suites remain, all AEAD, and every full handshake has forward secrecy. A downgrade sentinel in the last eight bytes of ServerHello.random (§4.1.3) lets a TLS 1.3 client detect an attacker forcing an older version. Heartbleed (2014), by contrast, was an OpenSSL implementation bug, not a protocol flaw.

Server authentication depends on X.509 certificate validation: a chain to a trusted root, a name matching a subjectAltName entry, validity dates, and revocation checking, which in practice is weak, one reason the CA/Browser Forum is shortening certificate lifetimes. Mutual TLS adds a client certificate and is common between services. Open problems include the metadata TLS leaves visible (IP addresses, sizes, and SNI unless Encrypted Client Hello, RFC 9849, is deployed) and quantum risk, addressed by the hybrid X25519MLKEM768 key exchange that major browsers and CDNs already negotiate. Compared with a VPN, TLS secures one application connection end to end at the transport/application boundary, while a VPN tunnels all IP traffic between a device and a network gateway; many "SSL VPN" products are in fact TLS carrying tunnelled IP packets.