TLS Extensions: SNI, Session Tickets, ALPN

TLS extensions are additional fields carried in the ClientHello and ServerHello messages. They extend the protocol without changing its core structure. Think of them like optional fields on a form. The core form has your name and address. Extensions let you add a phone number, a preferred language, or a special delivery instruction. Some extensions are essential for modern TLS to function.

SNI (Server Name Indication)

Imagine a large office building with one front door but fifty different companies inside. A visitor walks in and says “I’m here for a meeting.” The receptionist asks: “Which company?” Without that question, the receptionist wouldn’t know which floor to send them to.

Without SNI, a server hosting multiple websites on the same IP address has the same problem. The TLS handshake happens before any HTTP data is sent. The server needs to present a certificate, but it doesn’t know which website the client wants yet. Which certificate should it present?

SNI solves this. The client includes the desired hostname in the ClientHello as an extension. The server reads it and presents the correct certificate.

ClientHello Extensions:
    server_name: www.example.com


SNI is sent in plain text (it’s part of the unencrypted ClientHello).
This means an eavesdropper can see which hostname you’re connecting to,
even though the rest of the connection is encrypted. This is a known
privacy issue.
Encrypted Client Hello (ECH) is an emerging standard
that encrypts the SNI and other sensitive ClientHello extensions. It’s
being deployed gradually but isn’t universal yet.
Without SNI, the server would have to use a single certificate for
all hosted sites (a multi-domain SAN certificate) or use separate IP
addresses for each site. SNI made virtual hosting with HTTPS
practical.
Session Tickets
Covered in detail in the Session Resumption chapter. The
session_ticket extension in the ClientHello tells the
server the client supports session tickets. The server responds with a
NewSessionTicket message after the handshake.
ALPN
(Application-Layer Protocol Negotiation)
ALPN lets the client and server agree on the application protocol
during the TLS handshake, before any application data is exchanged.
ClientHello Extensions:
    application_layer_protocol_negotiation:
        - h2 (HTTP/2)
        - http/1.1

ServerHello Extensions:
    application_layer_protocol_negotiation:
        - h2

Without ALPN, the client would need to connect, complete the TLS
handshake, then negotiate the application protocol (an extra round
trip). ALPN eliminates that extra step.
ALPN is required for HTTP/2. Browsers will only use HTTP/2 over TLS
with ALPN negotiation. It’s also used for HTTP/3 (QUIC) discovery and
other protocols.
Other Notable Extensions

supported_versions: In TLS 1.3, this extension (not
the record layer version field) indicates the TLS version. This was
changed because middleboxes were breaking connections with unfamiliar
version numbers.
key_share: TLS 1.3 uses this to send the client’s
DH public values upfront in the ClientHello.
signature_algorithms: Lists which signature
algorithms the client supports for certificate verification and
handshake signatures.
supported_groups: Lists which elliptic curves or DH
groups the client supports for key exchange.


Next: Why TLS 1.3 Was
Necessary
← Previous ChapterNext Chapter →

TLS Extensions: SNI, Session Tickets, ALPN

SNI (Server Name Indication)

Session Tickets

ALPN (Application-Layer Protocol Negotiation)

Other Notable Extensions