How TLS 1.3 Works: Certificates, 1-RTT Handshakes, and Why 0-RTT Is Replayable

TCP can carry bytes in order. It cannot tell you who is on the other end, and it cannot stop a path observer from reading those bytes. HTTPS still speaks HTTP. The layer that authenticates the server and encrypts the stream is TLS.

TLS 1.3 is the version that now dominates the public web. It cut a round trip from the classic handshake, dropped obsolete ciphers, and made forward secrecy the default. This article explains what a certificate proves, how ClientHello and ServerHello produce traffic keys, what Finished binds, how session tickets resume a later connection, and why 0-RTT data is encrypted but not replay-safe.

It is not a second tour of the TCP handshake, QUIC packet types, or HTTP methods. See how TCP works, how QUIC works, how HTTP works, and what happens when you type a URL. The search intent here is one question: how does TLS 1.3 turn an untrusted byte pipe into an authenticated, confidential channel?

The contract

RFC 8446 defines TLS 1.3 as a protocol that runs over a reliable, in-order stream and produces server authentication via an X.509 chain, optional client authentication, confidentiality and integrity of application data using an AEAD such as AES-GCM or ChaCha20-Poly1305, and forward secrecy for 1-RTT keys derived from an ephemeral Diffie-Hellman share.

TLS does not replace TCP reliability. A lost segment still stalls the TLS record stream. A valid certificate for api.example.com does not mean the JSON body is honest; it means that body was written by someone who controls that name's key, as far as the client's trust store can tell.

Where TLS sits

application (HTTP, gRPC)
    -> TLS records
        -> TCP segments
            -> IP packets

On HTTP/3 the same TLS 1.3 handshake messages ride inside QUIC CRYPTO frames. The cryptographic contract is shared. The packet format is not.

Certificates are names bound to keys

A server certificate is a signed statement. A CA asserts that a public key belongs to a DNS name until an expiry, under key-usage constraints. The client trusts a finite list of roots. Validation walks leaf to intermediate to a root, checks subject alternative names against the requested hostname, and applies time, revocation, and browser policy such as Certificate Transparency.

A failed check must abort before application keys are used. Self-signed certificates authenticate nothing unless the client was configured to trust that exact key.

The 1-RTT handshake

After TCP is ESTABLISHED, a first-time TLS 1.3 handshake is one round trip when the client guessed a common group such as X25519.

The client sends ClientHello: supported_versions with 1.3, AEAD cipher suites, named groups, one or more key shares, a nonce, SNI, and optional ALPN.

The server answers with ServerHello, then EncryptedExtensions, Certificate, CertificateVerify, and Finished. It picks one suite and one group. The two key shares produce a shared secret. HKDF derives handshake traffic keys and later application traffic keys. CertificateVerify is a signature over the handshake transcript with the leaf private key. Finished is a MAC over the transcript. The client replies with Finished and may attach the first application data on the same flight.

On a clean path that is one cryptographic round trip on top of TCP. That is why a cold HTTPS connection is still two handshakes, and why QUIC collapsed them.

Records

Application data is wrapped in TLS records: content type, length, AEAD ciphertext. A sequence number feeds the nonce so a replayed record fails authentication. TLS 1.2-style renegotiation is gone. Long connections can send a key update.

Session resumption and 0-RTT

After a full handshake the server issues a session ticket. On the next connection the client sends the ticket in a pre_shared_key extension.

PSK plus a fresh ECDHE share resumes in 1-RTT with forward secrecy. 0-RTT instead derives early-data keys from the PSK and sends application bytes on the first flight. Those bytes are encrypted against observers and are replayable: an attacker who captured the flight can present it again. Treat 0-RTT as acceptable for an idempotent GET and dangerous for POST /transfer. QUIC 0-RTT inherits the same warning.

What TLS does not do

It authenticates the name, not the business. A phishing site can hold a valid publicly trusted certificate. It does not authenticate the path; a custom root installed on the client enables inspection. It does not compress safely. TLS 1.0, 1.1, and RSA key-transport ciphers are outside this contract.

A concrete failure mode

A client wants pay.example.com. An attacker aims TCP at a host holding a certificate for pay.example.net. TCP succeeds. TLS produces keys. Hostname verification fails. A correct client tears the connection down. If verification is disabled, encryption continues with the wrong peer.

Misconceptions

TLS is not the TCP handshake. A padlock is not page safety. 0-RTT is not merely a faster handshake. Disabling certificate checks on an internal network is still attaching encryption to an unauthenticated peer.

Takeaways

TLS 1.3 authenticates a name with a certificate chain and a transcript signature, then derives AEAD keys from an ephemeral Diffie-Hellman share mixed with handshake context. The first application record is one round trip after TCP is up, unless a ticket allows replayable 0-RTT early data. Hostname verification is not optional.