skip to content

In a TLS 1.3 handshake, what has both sides agreed by the time the client sends its first application byte?

level: juniorimportance: must knowfreq 74%

answer

  1. nothing application-level has happened yet
  2. one version, one suite, one protocol
  3. client offers lists, server picks one
  4. EncryptedExtensions carries the server's answers
  5. Finished is a MAC over the transcript

basics

~20 s

A completed TLS 1.3 handshake has fixed one protocol version and one cipher suite, derived shared traffic keys, established the server's identity by signature, selected an application protocol, and confirmed both peers saw an identical message transcript.

solid answer

~40 s

By the time a client writes the first byte of a ticket request, the negotiation is over. `ClientHello` and `ServerHello` pin exactly one protocol version and one cipher suite, chosen from what the client offered, and each side has contributed to the key exchange, so both can derive traffic keys. `EncryptedExtensions` carries the server's answers to the non-cryptographic extensions the client offered, including the selected application protocol and the acknowledgement of the host name that was asked for. The server then presents a certificate and signs the handshake so far, so it proves possession of the matching private key rather than merely holding a certificate. Finally each side sends `Finished`, a MAC over every handshake message, so both confirm they saw the same transcript. Only then does application data flow.

code

pseudocode · 10 lines
pseudocode
connection state once both Finished messages verify:

  version            = TLS 1.3
  cipher_suite       = TLS_AES_128_GCM_SHA256
  traffic keys       = derived from both key-exchange contributions
  server identity    = certificate + signature over the transcript
  application proto  = one entry taken from the client's offer
  transcript         = proven identical on both sides

  application data   = not yet sent

go deeper

for a junior

Be able to say, without notes, that the version, the cipher suite, the keys, the server's identity and the application protocol are all settled before the first request byte. Naming the two hello messages and Finished is enough at this stage.

for a middle

Explain the offer-and-select shape: the client sends lists, the server returns single values, and the client may still abort. Say which message carries which decision, and why Finished is a MAC over everything that came before.

for a senior

Show what this buys you when a connection misbehaves. Knowing that the suite came from the client's own list, or that the transcript was proven identical, narrows a live failure to one side of the exchange instead of leaving it as 'TLS broke'.

for a principal

Frame it as where the negotiation surface lives. What your fleet's clients are willing to offer is the real policy, because a server can only select from it, and that surface is what an estate-wide floor has to control.

## What a handshake is for A TLS handshake exists so two peers that have never spoken can agree every parameter the rest of the connection depends on, establish who the server is, and derive the keys that protect every byte afterwards. Nothing application-level happens while it runs. A national rail ticketing gateway accepting connections from platform machines, phone clients and partner retailers has not seen one character of a ticket request until the handshake completes — so "what does the connection already know?" is a fair first-screen question for anyone who has deployed a service behind TLS. ## The agreements, message by message (TLS 1.3) - **`ClientHello`** — the client *offers*: the versions it can speak, an ordered list of cipher suites, a key-exchange contribution, the host name it is trying to reach, and the application protocols it is willing to run. Everything the server later picks, it picks out of this offer. - **`ServerHello`** — the server names **exactly one** cipher suite and one version, and sends its own key-exchange contribution. From this point both sides can derive the handshake traffic keys. - **`EncryptedExtensions`** — the first handshake message protected under those keys. It carries the server's answers to the extensions that are not needed to establish the keys: the host-name acknowledgement, the selected application protocol, and so on. - **`Certificate`** and **`CertificateVerify`** — the server presents a certificate chain and then signs the transcript of the handshake so far. Presenting a certificate is not enough on its own; the signature is what ties the certificate to *this* connection. - **`Finished`** — a MAC computed over every handshake message sent so far, one from each side. A peer that verifies the other's `Finished` knows both transcripts are identical, so nothing in the negotiation was rewritten in flight. ## Where each agreement is decided | Agreement | Offered in | Settled in | |---|---|---| | Protocol version | `ClientHello` | `ServerHello` | | Cipher suite | `ClientHello` | `ServerHello` | | Traffic keys | both hello messages | derived by both sides, never sent | | Host name requested | `ClientHello` | acknowledged in `EncryptedExtensions` | | Application protocol | `ClientHello` | `EncryptedExtensions` | | Server identity | — | `Certificate` plus `CertificateVerify` | | Transcript agreement | — | `Finished`, in each direction | ## Who chooses what The grammar of the whole exchange is **the client offers, the server disposes**, and then the client may refuse the outcome: 1. The client's offer is a set of lists. The server must select from those lists — a suite the client never offered is not a legal choice, and a client that receives one aborts. 2. The server's selections are single values, not lists. One version, one suite, one application protocol. 3. The client checks the result and may still abort: the certificate may not satisfy it, or the parameters may be below the floor it is configured to accept. That asymmetry is why "the server picked a weak suite" is nearly always a statement about what the *client* was willing to offer. ## What is still open when the handshake ends Stating the limit matters as much as stating the benefit: - **Nothing application-level has been decided.** Whether this caller may buy a ticket, which account it is acting for, and what the request body says are all a layer above and have not been touched. - **The connection is authenticated in one direction in the ordinary case.** The client has evidence about the server; the server has learned nothing about the client unless it explicitly asked for a certificate, which is a separate exchange. - **The record layer takes over.** From here, protection is applied per record rather than per handshake message, and the parameters agreed above are what it uses. ## Version note TLS 1.2 reaches the same set of agreements but spreads them across more messages and protects almost none of them: its certificate and its extension answers travel in the clear, and only each side's `Finished` is protected, because record protection starts after the `ChangeCipherSpec` record. TLS 1.3 folds the same outcomes into fewer flights and moves everything after `ServerHello` under the handshake traffic keys. The agreements are the same; where they are visible is not.

  • In TLS 1.3 a server may send application data before the client's Finished arrives. What is the catch?
    The server has sent its own `Finished` and can write immediately, half a round trip early. But it has not yet verified the client's `Finished`, so at that instant it has no proof the peer completed the exchange or that a client certificate check succeeded. Anything written in that window is data the server commits to before the handshake is confirmed in both directions.
  • What does a client do when the server's Finished does not verify?
    It terminates the connection with a fatal `decrypt_error` alert and sends no application data. A `Finished` that fails to verify means the transcripts differ or the keys differ, which is exactly the condition the message exists to catch, so continuing would mean accepting a negotiation the two sides do not agree on.
  • Which of these agreements can change later on the same connection?
    The version, the cipher suite, the application protocol and the peer identity are fixed for the life of the connection. Only the symmetric keys in force can be replaced afterwards, and that is a record-layer mechanism rather than a renegotiation of anything agreed in the handshake.

It is the part of a phone call before anyone speaks: both parties have settled the language, checked that the voice on the line is the one they dialled, and agreed neither heard a different conversation.

saying these in an interview costs you the question

  • Says the handshake only exchanges encryption keys
  • Thinks application data may flow before Finished
  • Believes the server may pick a suite the client never offered
  • Confuses the application login session with the handshake outcome
  • Assumes presenting a certificate alone establishes the server's identity