ECH Without Padding Is a Lookup Table

You deployed Encrypted Client Hello. The server name is encrypted, the inner ClientHello is padded, and the censor watching your wire can no longer read which site a visitor asked for. Then they measure a few packet sizes and know anyway, because ECH without padding leaks the answer in plain sight.

That is not a hypothetical. We measured it on our own ECH deployment: every single virtual host behind the ECH listener, 8 out of 8 in the lab and 5 out of 5 in production, was uniquely identifiable from nothing but the sizes of the server’s encrypted handshake records. ECH without padding is a lookup table. An observer who probes each candidate hostname once, writes down the record sizes, and then watches passive traffic can read vhost identity straight through the encryption.

This article is the measured story of that leak, and of ssl_handshake_padding, the one-directive NGINX module we shipped to close it. Every number here comes from byte-exact TLS record captures against a real ECH stack: NGINX with OpenSSL 3.5, the same builds we ship in our RPM and DEB repositories.

The leak: TLS 1.3 tells you exact sizes

ECH solves the client side of the metadata problem. The inner ClientHello, with the real SNI, is encrypted and padded; we verified that the outer ClientHello is byte-identical (580 bytes) no matter which inner name the client asks for, and the ServerHello is uniform too (122 bytes).

But then the server sends its own encrypted flight: EncryptedExtensions, Certificate, CertificateVerify, Finished. TLS 1.3 encrypts the contents of those records and does nothing about their lengths. The ciphertext length is the plaintext length plus a small constant, visible to anyone on the path. And the dominant record in that flight is the certificate chain, which is different for every vhost.

How different does it need to be? One byte. We built two near-twin vhosts whose certificates differ by a single character in the subject. Their Certificate records came out at 942 and 943 bytes, and that one-byte gap was perfectly stable across handshakes. ECDSA signatures add a byte or two of jitter in CertificateVerify; RSA vhosts are byte-deterministic. Either way the noise is far too small to hide anything: all 8 lab vhosts stayed uniquely identifiable across every capture, including the near-twins.

Production looked exactly the same. The five vhosts on our own ECH listener produced Certificate records of 4101, 4112, 4751, 4751 and 4752 bytes: four distinct sizes, with two vhosts colliding only because they share the same certificate shape, and two others sitting one byte apart.

Certificate compression does not save you

A reasonable hope is that TLS certificate compression fixes this as a side effect. It does not. With compression enabled, the flights shrank by roughly 20 percent, and all 8 vhosts remained uniquely identifiable. Compression preserves size differences, and because compressed size depends on certificate content, it actually adds its own content-dependent fingerprint. Smaller lookup table entries, same lookup table.

The RFC saw this coming

This is not an obscure corner case that ECH’s designers missed. RFC 9849, the ECH specification itself, says in section 6.1.3 that “clients and servers will also need to pad all other handshake messages that have sensitive-length fields”, using TLS record layer padding, for the SNI protection to hold.

The mitigation is specified. What we could not find is anyone actually shipping it: no mainstream server pads its handshake flight, and none of the alternative NGINX package vendors offer anything comparable. So we built it.

The fix: one directive

nginx-module-handshake-padding is a small dynamic module that pads every outgoing TLS 1.3 handshake record up to a multiple of a block size you configure:

load_module modules/ngx_http_ssl_handshake_padding_module.so;

http {
    ssl_handshake_padding 512;
    ...
}

Under the hood it makes exactly one OpenSSL call per SSL context, using the handshake-only block padding API that exists in stock OpenSSL 3.4 and later. That design has three consequences worth spelling out:

• Zero application-data cost. Only handshake records are padded. Your HTML, JSON and video bytes go out exactly as before. Resumed sessions carry no Certificate at all, so their overhead is negligible.
• KTLS keeps working. Kernel TLS offload is disabled by OpenSSL’s per-record padding callback, but not by handshake-only block padding. If you use ssl_conf_command Options KTLS, this module does not take it away.
• No patches anywhere. It is a standard dynamic module. No patched NGINX, no patched OpenSSL, works on any NGINX running against OpenSSL 3.4+.

Padding rounds a record of wire size L up to ceil((L - 16) / N) * N + 16 bytes, where N is the configured block and 16 covers the AEAD tag and header overhead. Vhosts whose padded flights land on the same multiples become indistinguishable: they merge into one anonymity group.

Before and after, on production

We enabled ssl_handshake_padding 512; on web.getpagespeed.com, the same five-vhost ECH listener measured above, and re-captured.

Before: Certificate records of 4101, 4112, 4751, 4751, 4752 bytes. Four distinct sizes; every observer with a one-time probe of candidate names can classify traffic.

After: every server handshake record obeys the padding model exactly, and the five vhosts collapse into two groups, at 4112 and 5136 bytes. The vhosts inside each group are byte-identical on the wire. The two groups that remain are structurally different certificate chains, and that separation is by design, as the next section explains.

The cost at 512 is about 1.5 KB per full handshake, roughly one extra TCP segment, and nothing on resumed connections or application data.

You can reproduce this measurement on your own listener. Capture a handshake per vhost with tcpdump, read off the TLS record lengths of the server flight right after the ServerHello, and compare across your sites. If the numbers differ, your vhosts are distinguishable to anyone watching, exactly as ours were.

Choosing a block size

We modelled the exact padding arithmetic on the lab captures across the whole range. The lab matrix deliberately mixes certificate shapes: four vhosts on Let’s Encrypt style EC P-256 certificates, two on RSA-2048, one RSA-4096, one with a two-intermediate chain.

Two things fall out of this table.

First, small blocks already do the useful work. At 256 or 512, all vhosts with the same certificate shape merge, and that is the case that matters in real deployments, where a server typically carries many Let’s Encrypt certificates of one type. The byte-level and near-twin distinctions, the actually dangerous fingerprints, are gone at 512.

Second, buying a single anonymity group across structurally different chains is expensive and mostly wasted. The block API pads every handshake record, so tiny records like EncryptedExtensions and Finished balloon to a full block each at large sizes. Worse, at 4096 the padded flight reaches about 16.4 KB, which spills past a typical 10-segment initial congestion window and costs an extra round trip on every fresh connection. The module logs a warning if you configure that.

The practical guidance is the inverse of what intuition suggests: do not reach for huge padding, reach for uniform certificates. Same-shape chains plus ssl_handshake_padding 512 beat heroic block sizes on both privacy and performance.

What padding cannot fix

Honesty about limits is part of the measurement story:

• HTTP/3 is not covered. OpenSSL’s padding API refuses QUIC SSL objects, so QUIC handshake sizes remain unpadded. Clients that connect over TCP first (which is how they discover h3 via Alt-Svc) get the protection on that first, most identifying handshake, but the h3 side is an open problem for the whole ecosystem.
• Response sizes still talk. The first application response length differs per site, and a stable page size is itself a classifier. Padding application data costs bandwidth on all traffic and is out of scope here.
• The anonymity set is the listener. Padding makes vhosts behind one ECH listener mutually indistinguishable. If a server hosts a single site, there is nothing to hide it among, and padding buys nothing there.

None of this diminishes the handshake fix. ECH without padding fails at its own core promise; with padding, that promise holds for the handshake, not more.

Get it

The module is in the GetPageSpeed repository for every platform we package, RHEL and friends from EL7 through EL10, Fedora, Amazon Linux, SUSE, Debian and Ubuntu, on x86_64 and aarch64:

# RPM-based
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-handshake-padding

# DEB-based
curl -sSL https://extras.getpagespeed.com/deb.sh | bash
apt -y install nginx-module-handshake-padding

Then load it and set one directive, as shown above. The module ships with a packet-level regression test that asserts padded record sizes match the model on every build.

If you are rolling out ECH itself, start with our ECH guide, which covers the full stack we ship: NGINX with the DEfO ECH-enabled OpenSSL 3.5, post-quantum key exchange, and now the server-side size leak closed. To our knowledge this makes it the only packaged NGINX where the RFC 9849 padding recommendation is actually implemented; every other build ships ECH without padding on the server flight. Here it is one dnf install away. Subscribe to the GetPageSpeed repository to get it, along with 100+ NGINX modules built against the same stack.