Understanding TLS ClientHello and SNI

Foundations of Secure Networking

Every secure internet connection — whether you're visiting a website, using an API, or connecting to a messaging service — begins with a deceptively small but powerful exchange: the TLS handshake.

At the heart of that handshake lies the ClientHello message and an important extension within it: the Server Name Indication (SNI). This post breaks down the purpose, structure, and role of these two elements in modern network communication — without diving into code.


🌐 Why TLS Handshake Exists

TLS (Transport Layer Security) is the protocol that secures almost all internet communication today — from HTTPS and SMTP to VPNs and instant messaging.

The TLS handshake:

  • Negotiates encryption algorithms and versions

  • Exchanges key material securely

  • Verifies the identity of the server (and optionally the client)

  • Establishes trust and encryption before any sensitive data is sent

The handshake always begins with a message from the client called ClientHello.


🤝 What is ClientHello?

ClientHello is the first message in the TLS handshake. It acts as the client saying:

“Hey server, I want to start a secure conversation. Here’s what I support.”

This message includes:

  • The client’s supports TLS version

  • A list of cryptographic algorithms (cipher suites)

  • A random value used for key generation

  • Optional extensions — including SNI, ALPN, session resumption, etc.


🧩 The Role of Extensions

TLS is designed to be extensible. One of its most important extensions is the Server Name Indication (SNI).


🔐 What is SNI?

SNI (Server Name Indication) is an optional — but widely adopted — TLS extension that allows the client to tell the server:

“I’m trying to connect to example.com.”

This is critical in modern hosting setups, where:

  • One IP address hosts multiple TLS domains

  • Servers need to choose the correct certificate to present

  • Traffic routing decisions depend on the hostname

Without SNI, the server wouldn’t know which certificate to serve before the encrypted channel is established.


🧱 TLS Record and Handshake Layer

When a TLS connection begins, the client sends a TLS Record, which contains the ClientHello.

The TLS Record is structured as:

Field
Size
Description

Content Type

1

Indicates handshake (value: 0x16)

Protocol Version

2

TLS version (e.g., 0x03 03 for TLS 1.2)

Length

2

Number of bytes in this record

Immediately following this record header is the Handshake Layer, starting with the ClientHello.


📦 ClientHello Structure (Simplified)

The ClientHello The message includes multiple fields:

  • TLS version the client supports

  • A random number (used in key derivation)

  • A Session ID (for resuming sessions)

  • A list of supported cipher suites

  • Supported compression methods

  • A list of extensions, including SNI

It’s inside the extensions section where the SNI is located.


🔍 SNI Extension Internals

The SNI extension contains:

  • A list of hostnames (almost always just one)

  • Each with a name type (typically host_name)

  • A length field

  • The actual domain name the client wants to reach

This is what enables TLS to support virtual hosting — multiple domains, one IP.


🌍 Why This Matters

In Production Systems:

  • Reverse proxies (like Nginx, HAProxy, Traefik) use SNI to route TLS traffic before completing the handshake.

  • Certificate managers (like Let's Encrypt or cert-manager) use SNI to know which domain is being validated.

  • Firewalls or custom proxies might peek at the SNI to allow/block based on domain names.

In Observability:

  • Tools like Wireshark or TLS inspectors can log which domains are being accessed via SNI.

  • It allows passive monitoring of TLS traffic without decrypting payloads.


🧠 Key Takeaways

[ 0x16 ][ 0x03 0x03 ][ 0x01 0x2C ] ... [ ClientHello starts here ] ↑ ↑ ↑ Handshake TLS 1.2 Payload = 300 bytes

Concept
Purpose

TLS Handshake

Establishes encrypted, trusted communication

ClientHello

First message sent by client; declares capabilities

SNI

Extension that tells server the target hostname

Importance

Enables certificate selection, routing, virtual hosting

Visibility

SNI is sent in cleartext, before encryption starts


⚠️ SNI Privacy Considerations

While TLS encrypts almost everything after the handshake begins, the SNI value is exposed in plaintext.

To address this, a newer standard called Encrypted Client Hello (ECH) is being developed and adopted. But as of today, SNI is still visible to passive observers (e.g., network firewalls, ISPs).


✅ Final Thoughts

Understanding the ClientHello and SNI is foundational to mastering TLS and secure communication. Whether you're building reverse proxies, inspecting network packets, or designing secure architectures, knowing what's inside the handshake gives you powerful insight and control.

It’s one of those elegant protocols where a few bytes exchanged up front determine the entire course of a secure connection.

Last updated