yum upgrades for production use, this is the repository for you.
Active subscription is required.
Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX
Problem Statement
Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server’s encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer can fingerprint which vhost a client connected to purely from server handshake record sizes, defeating a key privacy goal of ECH.
Measured Leak
On a real ECH stack—NGINX with OpenSSL 3.5, using the same builds shipped in RPM and DEB repos—every vhost behind the ECH listener was uniquely identifiable from server handshake record sizes alone:
- 8 out of 8 vhosts in the lab
- 5 out of 5 in production
Two near-twin vhosts whose certificates differed by a single subject character produced stable Certificate records of 942 and 943 bytes. Production Certificate records measured 4101, 4112, 4751, 4751, and 4752 bytes—four distinct sizes.
Certificate compression does not fix it
With TLS certificate compression enabled, flights shrank ~20 percent, but all 8 vhosts remained uniquely identifiable. Compression preserves size differences and adds its own content-dependent fingerprint—smaller lookup table entries, same lookup table.
The spec already calls for a mitigation
RFC 9849 section 6.1.3 specifies padding all other handshake messages with sensitive-length fields using TLS record layer padding. No mainstream server ships it, and no alternative NGINX package vendor offers anything comparable.
The Fix: nginx-module-handshake-padding
A small dynamic module that pads every outgoing TLS 1.3 handshake record to a multiple of a configured block size:
load_module modules/ngx_http_ssl_handshake_padding_module.so;
http {
ssl_handshake_padding 512;
...
}
It makes exactly one OpenSSL call per SSL context using the handshake-only block padding API in stock OpenSSL 3.4 and later. It does not interfere with ssl_conf_command Options KTLS.
Padding arithmetic
A record of wire size L is rounded up to:
ceil((L - 16) / N) * N + 16
where N is the block size and 16 covers AEAD tag and header overhead. Vhosts whose padded flights land on the same multiples merge into one anonymity group.
Measured result at ssl_handshake_padding 512;
On the same five-vhost ECH listener:
- Before: four distinct Certificate sizes
- After: all records obey the padding model exactly; the five vhosts collapse into two groups at 4112 and 5136 bytes, byte-identical within each group
The two remaining groups are structurally different certificate chains, separated by design. Cost is about 1.5 KB per full handshake (~one extra TCP segment), nothing on resumed connections or application data.
Lab Matrix Findings
Tested with four EC P-256 Let’s Encrypt-style certs, two RSA-2048, one RSA-4096, and one two-intermediate chain:
- Small blocks already do the useful work. At 256 or 512, all vhosts with the same certificate shape merge—the case that matters in real deployments carrying many same-type Let’s Encrypt certificates. Byte-level and near-twin distinctions disappear at 512.
- Buying one 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. At 4096 the padded flight reaches ~16.4 KB, spilling past a typical 10-segment initial congestion window and costing an extra round trip on every fresh connection. The module logs a warning if you configure that.
- Practical guidance is the inverse of intuition: don’t reach for huge padding, reach for uniform certificates. Same-shape chains plus
ssl_handshake_padding 512beat heroic block sizes on both privacy and performance.
Reproduce It Yourself
Capture a handshake per vhost with tcpdump, read the TLS record lengths of the server flight right after ServerHello, and compare across sites. Differing numbers mean your vhosts are distinguishable to any observer.
Stated Limitations
- Padding only closes the handshake size leak, not other side channels.
- It does not address TLS 1.2 or earlier.
- It does not hide the fact that ECH is in use.
- It does not protect against an observer who can correlate traffic across connections or observe application data patterns.
Availability
In the GetPageSpeed repository for RHEL and friends 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
Ships with a packet-level regression test asserting padded record sizes match the model on every build. For ECH rollout, the full stack includes NGINX with DEfO ECH-enabled OpenSSL 3.5, post-quantum key exchange, and now the server-side size leak closed.
Read the full article: ECH Without Padding Is a Lookup Table
