Description: When using a Traefik TCP router with a HostSNI rule to multiplex encrypted traffic, Traefik fails to read the Server Name Indication (SNI) if the client uses a Post-Quantum Cryptography (PQC) hybrid key exchange (e.g., X25519MLKEM768). Because the SNI cannot be read, Traefik falls back to its default behavior, serving the TRAEFIK DEFAULT CERT and dropping the connection.
Root Cause: PQC hybrid key exchanges add >1,100 bytes to the TLS 1.3 ClientHello. This routinely pushes the total packet size beyond the standard 1500-byte network MTU. The ClientHello is subsequently fragmented across two TCP segments. The SNI extension ends up in the second segment. Traefik's TCP SNI sniffer/peek buffer does not appear to reassemble the fragmented TLS record or buffer deeply enough to reach the SNI in the second packet before making a routing decision.
Environment:
-
Traefik Version: v3.x
-
Client: Latest CachyOS / Arch Linux shipping OpenSSL and
curlwith ML-KEM enabled by default. -
Architecture: TCP Router (
rule=HostSNI("``example.com``")) passing through to a backend or terminating TLS.
Steps to Reproduce:
-
Configure a Traefik TCP router matching a specific SNI.
-
From a PQC-enabled client, attempt a connection:
curl -v -I https://example.com -
Observe Traefik silently failing the SNI match and serving the Default Certificate.
-
Force standard elliptic curves:
curl --curves X25519 -v -I https://example.com -
Observe an instant, successful connection.
Proposed Solution: Increase the byte limit of the Peek() buffer used during TLS SNI extraction in the TCP multiplexer, and ensure it can buffer across TCP segment boundaries to read the full ClientHello up to the TLS record length.