The TLS handshake, 1.2 and 1.3

TLS negotiates mechanisms before protecting application data

Real TLS gives names to the nonces, certificate, Diffie-Hellman values and MACs in the conceptual flow. TLS 1.2 and TLS 1.3 differ in how that handshake runs.

Negotiation. TLS negotiates concrete ciphers, hash functions and MACs between the two parties, a practice common across many cryptographic protocols. The TLS standard defines codepoints for supported mechanisms: the client proposes a suite, and the server either picks its preference from that suite or rejects the connection. TLS also supports extensions, including Server Name Indication (SNI), which states the domain name a connection is meant for, plus mechanisms that identify the protocol being protected, indicate use of an application-layer protocol, or add features like Certificate Transparency.

The Record Protocol carries the other TLS subprotocols

Subprotocols. TLS is message-based; its subprotocols define the message exchanges. The Record Protocol embeds messages and maps them onto TCP, and is the base the others run on top of. The Handshaking Protocols are a group consisting of the Handshake Protocol (a specific protocol name, not the name of the group), Change CipherSpec (signals a transition to different cryptography), and Alert (signals errors). Separately, TLS Application Data carries the secured payloads.

Pitfall

“Handshake Protocol” names one specific protocol within TLS, not the broader category of protocols involved in the handshake phase. That broader category is the “Handshaking Protocols” group, which also includes Change CipherSpec and Alert. An answer that treats the two names as interchangeable will lose the distinction the lecture explicitly calls out.

TLS 1.2 exchanges named handshake messages before the payload

The Handshake Protocol’s messages. These map directly onto the abstract flow from the previous page:

• ClientHello: version number, nonce, cipher suites.
• ServerHello: version number, nonce, cipher suites, session ID.
• ServerCertificate: the certificate.
• ServerKeyExchange: the Diffie-Hellman parameter.
• ClientKeyExchange: the Diffie-Hellman value.
• Finished: the MACs.

Change CipherSpec messages may appear before or after Handshake Protocol messages; they signal that the messages that follow use (different) encryption.

TLS 1.2’s handshake, in order. The client first establishes its security capabilities: protocol version, session ID, cipher suite, compression method, and an initial random number. The server may then send its certificate, a key exchange message, and a certificate request, before signalling the end of the hello phase. The client sends its certificate if one was requested, sends its key exchange message, and may send a certificate verification message. The server then switches cipher suite and finishes the handshake protocol. Only after all of this does the client send the application payload.

TLS 1.3 restricts ciphers and reaches one round trip

TLS 1.3. TLS 1.2 was already the product of many improvements over TLS 1.0 and 1.1, but it kept weaknesses from relatively old cryptography: MAC-then-encrypt instead of encrypt-then-MAC, and the use of compression. From around 2008, pressure on the protocol became serious enough that a redesign was needed.

Compare

TLS 1.2

Allows a null cipher (authentication without encryption). Certificates and Diffie-Hellman values are not encrypted.

TLS 1.3

Disallows null ciphers and permits only AEAD ciphers, such as AES-GCM or ChaCha20-Poly1305. Diffie-Hellman is the default except for one pre-shared-key mode. Encryption starts immediately after ServerHello, so certificates and Diffie-Hellman values (KeyShare) are encrypted and integrity-protected. Achieves 1-RTT: the client can send application data after one round trip.

TLS 1.3’s 1-RTT handshake, in outline: the client sends a TLS hello message proposing a key-agreement protocol, parameters, and the cipher suites it supports. The server sends its own hello, choosing the key agreement protocol, parameters, cipher suite, and a server-signed certificate. The client then checks that certificate, generates its key, and can immediately make an application request, e.g. an HTTPS GET.

Zero-RTT resumption gives up forward secrecy and replay protection

TLS 1.3’s 0-RTT. TLS 1.2 offered two session-resumption features, both achieving resumption in just one RTT: a Session Identifier, letting the server look up a previous key, and a Session Ticket, a token the client holds and sends back to resume the connection. TLS 1.3 deprecates both and replaces them with a pre-shared key mode, conceptually similar to a session ticket, signalled using the Early Data extension. This is an intentional design choice that acknowledges the weaknesses it brings.

0-RTT trades away two properties. The session key it reuses is not forward-secure: if it is later compromised, all data encrypted under it becomes readable. It also has no replay protection, so a captured 0-RTT request can be resent. The lecture restricts 0-RTT to idempotent application-layer messages, such as an HTTP GET, for exactly this reason, and notes it is unknown whether operators will actually implement that restriction correctly.

Exam detail

Keep three things exact: the six Handshake Protocol message names in order, the two properties TLS 1.3 gives up in 0-RTT (forward secrecy and replay protection) and why that restricts it to idempotent requests, and which two TLS 1.2 features (Session Identifier, Session Ticket) TLS 1.3 replaces with the pre-shared key mode.

Recall

Which subprotocol carries TLS messages, and what changes in TLS 1.3 and 0-RTT?

• The Record Protocol is the base; the Handshake Protocol, Change CipherSpec, Alert, and Application Data all run on top of it.
• Handshake message order: ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, ClientKeyExchange, Finished.
• TLS 1.3 mandates AEAD ciphers, encrypts the handshake from right after ServerHello, and reaches 1-RTT.
• TLS 1.3’s 0-RTT mode is not forward-secure and has no replay protection, so it is restricted to idempotent requests.