Jenseits des Post-Quanten-Ballasts: Engineering-Strategien zur Eindämmung von TLS-Handshakes

In meinem vorherigen Beitrag haben wir untersucht, wie sich die Post-Quanten-Schlüsselvereinbarung auf die Performance auswirkt. Die kurze Antwort? Die CPU-Auslastung ändert sich kaum, aber die Größe des TLS-Handshakes nimmt deutlich zu. Der Umstieg vom klassischen X25519 auf das hybride X25519MLKEM768 fügt dem TLS-Handshake in der kritischen Richtung etwa 1,2 KB hinzu. Wenn zwangsläufig noch Post-Quanten-Signaturen (wie ML-DSA) hinzukommen, überschreiten Zertifikatsketten leicht das anfängliche TCP-Überlastungsfenster (14,5 KB). Das erzwingt zusätzliche Round Trips (RTTs) und verursacht spürbare Netzwerklatenz.

Die Web-PKI bewegt sich bereits in Richtung Merkle Tree Certificates (MTCs), die in erster Linie für genau dieses Problem sehr langer Post-Quanten-Signaturen entwickelt wurden. Allerdings werden nicht alle Systeme MTCs nutzen können. Deshalb wollte ich in diesem Blogbeitrag untersuchen, was wir sonst noch tun können. Und das ist tatsächlich eine ganze Menge.

Wir haben zwei zentrale technische Hebel: Der eine besteht darin, die physische Größe des TLS-Handshakes zu verringern, der andere darin, zu reduzieren, wie oft überhaupt ein vollständiger Handshake stattfindet.

Hier ein praktischer Blick darauf, wie wir beides optimieren können – und wo die Branche bei der Standardisierung dieser Lösungen steht. Das Beste daran: Sie profitieren von diesen Optimierungen schon heute, selbst mit klassischer Kryptografie (RSA und/oder elliptische Kurven).

Wenn es um den TLS-Handshake geht, haben wir mehrere Optionen:

• Root-Zertifikate aus den Ketten entfernen: Einer der häufigsten Konfigurationsfehler ist die Übertragung des Root-CA-Zertifikats zusammen mit den Zwischenzertifikaten. Clients speichern Vertrauensanker bereits lokal; sie über die Leitung zu senden, erfüllt keinerlei Funktion und verschwendet wertvolle Bandbreite.
• Zertifikatskomprimierung einsetzen (RFC 8879): RFC 8879 ermöglicht es Endpunkten, Standard-Komprimierungsalgorithmen (Brotli, zlib oder zstd) für Zertifikatsdaten auszuhandeln. In der Praxis werden umfangreiche Zertifikatsketten dadurch um 30 % bis 50 % komprimiert. Zwar ist die Unterstützung in modernen Browsern uneinheitlich (Chrome unterstützt Brotli; Firefox unterstützt Brotli, zlib und zstd; Safari unterstützt zlib), doch OpenSSL unterstützt alle drei, sodass diese Technik einige Einsparungen bringen sollte. Leider funktioniert die Komprimierung nur für den in Zertifikaten enthaltenen Text. Signaturen und öffentliche Schlüssel lassen sich konstruktionsbedingt schlecht komprimieren.
• Öffentliche Schlüssel modernisieren (ECC statt RSA): Falls Sie noch nicht von veralteten RSA-Zertifikaten migriert sind, tun Sie es jetzt. Der Wechsel von RSA-2048 zu ECDSA verringert sofort die Größe von öffentlichen Schlüsseln und Signaturen und sorgt für kleinere Zertifikatsdaten, noch bevor PQC eingeführt wird.
• Raw Public Keys (RFC 7250): Für Machine-to-Machine-Kommunikation, APIs oder eingeschränkte Umgebungen, in denen Endpunkte dem öffentlichen Schlüssel des Servers bereits vertrauen oder ihn über einen separaten Kanal zwischenspeichern, können Sie mit RFC 7250 die Übertragung von Zwischen-CAs und Zertifikatshüllen vollständig überspringen.

Die IETF hat mehrere weitere Mechanismen zur Komprimierung und Verkleinerung untersucht, wobei die Verbreitung sehr unterschiedlich ist:

• TLS Cached Info (RFC 7924): Soll Clients ermöglichen, zwischengespeicherte Zertifikate zu signalisieren, um eine erneute Übertragung zu vermeiden. Dieser RFC wurde im Mai 2026 veröffentlicht, wird aber von Bibliotheken und User Agents noch nicht breit unterstützt. Vielleicht verbessert sich die Unterstützung, sobald wir mit der Migration zur Post-Quanten-Kryptografie beginnen.
• Abridged Compression for WebPKI Certificates (draft-ietf-tls-cert-abridge): Nutzt vorab verteilte statische Wörterbücher, um Zertifikatsstrukturen zu komprimieren. Obwohl der Entwurf von der TLS Working Group angenommen wurde, ist er inzwischen abgelaufen und scheint tot zu sein.

In TLS gibt es zwei Arten von Handshakes: vollständige und verkürzte (wiederaufgenommene). Letztere enthalten keine Zertifikate und bedeuten daher eine erhebliche Einsparung:

• Sitzungswiederaufnahme (Session Resumption): Mit der Sitzungswiederaufnahme können sich wiederkehrende Clients über einen symmetrischen Pre-Shared Key authentifizieren und den aufwendigen asymmetrischen Schlüsselaustausch sowie die Zertifikatsübertragung vollständig überspringen.
• TLS 1.3 0-RTT (Early Data): Für wiederkehrende Besucher ermöglicht 0-RTT, dass Anwendungsdaten bereits im allerersten Paketflug zusammen mit dem Wiederaufnahme-Handshake übertragen werden, wodurch die Round-Trip-Verzögerungen des Handshakes ganz entfallen. Diese Technik bietet keine vollständige Forward Secrecy und sollte nur eingesetzt werden, wenn der erste Flug des User Agents keine sensiblen Informationen enthält.

Der schnellste Handshake ist der, den Sie nie durchführen müssen. Wer asymmetrische Austausche vermeidet, umgeht auch den wachsenden Größennachteil von Post-Quanten-Schlüsseln.

• Keep-Alives optimieren: Lassen Sie inaktive TCP- oder TLS-Verbindungen nicht vorzeitig abbrechen. Längere Keep-Alive-Timeouts auf Anwendungs- und TCP-Ebene an Edge-Proxys (z. B. NGINX, HAProxy, Envoy) halten Sockets für stoßweisen oder sequenziellen Client-Traffic aktiv.
• HTTP/2 und HTTP/3 (QUIC) einsetzen: Durch das Multiplexing mehrerer HTTP-Anfragen über eine einzige zugrunde liegende Verbindung beseitigen moderne Protokolle die verschwenderische Gewohnheit, parallele TLS-Sitzungen für Ressourcen auf demselben Origin zu öffnen.

Bei der Optimierung der TLS-Performance dreht sich die Diskussion fast immer um eingehenden (Frontend-)Traffic – also darum, wie Clients sich mit Ihren Edge-Servern verbinden. Doch bei modernen Microservice-Architekturen, Unternehmensnetzwerken und Cloud-nativen Anwendungen verursacht ausgehender (Egress-)Traffic einen enormen, versteckten Latenznachteil.

Jedes Mal, wenn ein interner Dienst einen ausgehenden API-Aufruf startet, eine Abhängigkeit von Drittanbietern abruft oder über Cluster in mehreren Regionen hinweg kommuniziert, löst er einen neuen TLS-Handshake aus.

Rechnet man den Post-Quanten-Overhead in diese internen Microservice-Meshes ein, wächst die kumulierte Latenz rasant. So lässt sich das auf der Egress-Seite abmildern:

• Forward Proxys mit Connection Pooling einsetzen: Ein ausgehender Forward Proxy (oder ein Service-Mesh-Sidecar wie Envoy) zwischen Ihren internen Microservices und externen Endpunkten ermöglicht es, Verbindungen zu bündeln und in einem Pool zu verwalten. Statt dass jeder kurzlebige Anwendungs-Thread seinen eigenen Post-Quanten-TLS-Handshake zu einem externen Endpunkt aufbaut, hält der Forward Proxy einen Pool persistenter, langlebiger TLS-Verbindungen vor.
• Egress-Keep-Alives und Wiederaufnahme: Wie bei Frontend-Proxys sorgt eine konsequente Abstimmung von Sitzungswiederaufnahme und Keep-Alive-Einstellungen auf der ausgehenden Proxy-Infrastruktur dafür, dass interne Anwendungen von warmen Verbindungen mit geringer Latenz profitieren.

Indem Sie sowohl die Frontend-Auslieferung als auch die Egress-Infrastruktur optimieren, schützen Sie Ihre Endnutzer und Ihre interne Architektur vor der unvermeidlichen Byte-Inflation der Post-Quanten-Kryptografie.