In TLS, what does a resumption handshake presenting a previously issued ticket skip that a full handshake performs?

## The four jobs a full handshake does Before a single application byte moves, a full TLS handshake does four separable things: 1. **Negotiates** a protocol version and a cipher suite. 2. **Establishes a shared secret** through a key exchange that an observer cannot reproduce. 3. **Authenticates the server**, by sending a certificate chain and (in TLS 1.3) a signature over the handshake transcript so far. 4. **Confirms the transcript**, with a `Finished` message from each peer that MACs everything both sides believe they exchanged. Jobs 2 and 3 cost asymmetric cryptography, and job 3 also costs kilobytes on the wire - the `certificate_list` a server sends is usually the largest thing in the handshake. ## What resumption substitutes Resumption is the protocol's answer for a client that completed all four jobs with this server minutes ago. Rather than rebuilding trust from a certificate, both ends reuse a secret produced by that earlier, fully authenticated handshake. Which object carries it depends on the version: - **TLS 1.2, identifier form.** The client puts the `SessionID session_id` it was given into its `ClientHello`. If the server still holds the matching state, it echoes that identifier in its `ServerHello` and both sides go straight to `ChangeCipherSpec` and `Finished`. - **TLS 1.2, ticket form.** The client presents the opaque blob it received in a `NewSessionTicket` message, inside the `SessionTicket` extension of RFC 5077. - **TLS 1.3.** RFC 8446 pointedly does not resume a *session*: the earlier connection's `resumption_master_secret` yields a pre-shared key, and the ticket naming it is offered in the `pre_shared_key(41)` extension. ## The ledger | Handshake step | Full handshake | Resumption handshake | |---|---|---| | Version and cipher-suite negotiation | yes | yes | | Fresh per-connection randoms | yes | yes | | Server `Certificate` and chain | yes | no | | `CertificateVerify` signature | yes | no | | Client builds a path to a trust anchor | yes | no | | Key exchange | yes | only if the resumption asks for one | | `Finished` from each peer | yes | yes | | New record-protection keys | yes | yes | The certificate side is the whole of what disappears. Everything that makes *this* connection distinct from the last one survives, because it must: two connections deriving identical record keys would destroy the per-record nonce discipline the record layer depends on. ## Authentication without a certificate The most common misreading is that a resumed connection is unauthenticated because no certificate crossed the wire. It is authenticated - just not freshly and not by signature. Only a peer that holds the pre-shared key (or the TLS 1.2 master secret behind the identifier) can produce a `Finished` that verifies, so acceptance of the handshake is itself proof of possession of a secret that the original certificate-authenticated handshake created. The trust is inherited, and its age is bounded by the lifetime the server put on the ticket. That inheritance is also the limit. If the server's identity has changed - a re-issued certificate, a revoked one - a resumption will not notice, which is one reason servers cap ticket lifetimes rather than issuing open-ended ones. ## Round trips, stated honestly - **TLS 1.2:** a full handshake needs two round trips before application data; the abbreviated handshake needs one. Resumption genuinely buys a round trip here. - **TLS 1.3:** a full handshake already completes in one round trip. A resumption handshake is *also* one round trip. It saves the chain bytes and the asymmetric operations, not the wait. Only 0-RTT early data, offered with `early_data(42)` against a ticket that permitted it, puts application data in the client's very first flight. Stating this wrongly is the single most common answer defect on this material, because the TLS 1.2 intuition is repeated after the mechanism it described has gone. ## What the server can always do instead Acceptance is never guaranteed. A server may ignore the offered identifier or ticket - because it expired, because this server cannot open it, or because policy says so - and simply run a full handshake. In TLS 1.2 the client sees a different `SessionID session_id` come back; in TLS 1.3 it sees no `pre_shared_key(41)` in the `ServerHello`. A client that cannot tolerate that fallback is broken, not unlucky.