The TLS handshake, 1.2 and 1.3

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.

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.

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. 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.

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.

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.