← Back to Table of Contents

TLS 1.3 Extensions

TLS 1.3 moved several negotiation functions out of the cipher suite and into extensions. This makes the protocol more modular and extensible.

Key Extensions

supported_versions: Indicates which TLS versions the client supports. In TLS 1.3, this extension (not the legacy version field in the record header) determines the protocol version. The record header still says TLS 1.2 (0x0303) for compatibility with middleboxes.

key_share: Contains the client’s ephemeral DH public values. The client can include multiple key shares (e.g., X25519 and P-256) so the server can pick one without a round trip.

signature_algorithms: Lists which signature algorithms the client supports for CertificateVerify and certificate chain verification. Separates signature algorithms from cipher suites.

signature_algorithms_cert: Optionally specifies different signature algorithms for certificate chain verification vs handshake signatures.

pre_shared_key: Contains PSK identities for session resumption.

psk_key_exchange_modes: Indicates whether the client supports PSK-only or PSK with ECDHE.

early_data: Indicates the client is sending 0-RTT data.

Cookie Extension

If the server sends a HelloRetryRequest (asking the client to retry with different parameters), it can include a cookie. The client must echo this cookie in the new ClientHello. This serves two purposes:

1. Statelessness: The server can encode its state in the cookie instead of keeping it in memory between the HelloRetryRequest and the new ClientHello.
2. DoS protection: The cookie proves the client received the HelloRetryRequest, preventing certain amplification attacks.

Post-Handshake Authentication (PHA)

In TLS 1.2, if the server wants client authentication, it must request it during the handshake. In TLS 1.3, the server can request client authentication after the handshake is complete, using the post_handshake_auth extension.

The client indicates support in the ClientHello. Later, the server can send a CertificateRequest at any time, and the client responds with its certificate and CertificateVerify.

This is useful for applications where authentication requirements change during the session (e.g., a user accesses a protected resource after initially browsing public pages).

ALPN in TLS 1.3

ALPN works the same as in TLS 1.2 but is even more important. HTTP/2 requires ALPN. HTTP/3 (QUIC) uses ALPN to negotiate the protocol. The EncryptedExtensions message in TLS 1.3 carries the server’s ALPN selection, which is now encrypted (unlike TLS 1.2 where it was in the plain-text ServerHello).

---

Next: Middleboxes and Migration Pain