TLS 1.3

This overview describes TLS 1.3. TLS carries a sequence of records. Before encryption, handshake data is carried in TLSPlaintext records; the legacy record-version field exists for interoperability and TLS 1.3 peers do not use it to negotiate the protocol. Records are limited to 2^14 bytes of content before permitted expansion.

Handshake #

The client sends ClientHello with a random value, supported cipher suites, key shares, extensions, and a legacy session ID. Its legacy_version is 0x0303; the supported-versions extension negotiates TLS 1.3. Current standard AEAD suites include AES-GCM and ChaCha20-Poly1305 with SHA-256 or SHA-384.

The server replies with ServerHello, selecting a suite and key share. It can instead send HelloRetryRequest when it needs a different acceptable key share; the client then sends a second ClientHello containing the requested change. Both parties derive handshake traffic secrets from the key exchange and transcript, authenticate the handshake with Finished, and derive application traffic secrets. The server sends its Certificate and CertificateVerify when certificate authentication is used.

TLS 1.3 encrypts handshake messages after ServerHello and removes obsolete RSA key transport and static-DH negotiation. Certificate validation remains essential: clients verify the chain to a trusted issuer, the hostname or service identity, validity periods, key usage, signature algorithms, and relevant revocation policy. A certificate authority issues a certificate after validating control of a DNS name or other subject identity; the certificate binds that identity to a public key.

For certificate encoding, path construction, and local trust anchors, see X.509 Certificates and Cryptographic Trust Stores.