Das QPACK-Problem von HTTP/3 zeigt: Mehr Tempo kann die Angriffsfläche vergrößern

Was wäre, wenn das nächste Tempozuwachs des Webs Angreifern zugleich eine günstigere Möglichkeit gäbe, Server zum Verbrauch von Ressourcen zu zwingen? Hinter den jüngsten Berichten über QPACK-Verstärkungsangriffe steht genau diese unbequeme Frage. HTTP/3 scheitert nicht, weil seine Grundidee verfehlt wäre. Es scheitert teilweise daran, dass jede Optimierung neue Zustände, neue Übersetzungsschichten und neue Annahmen erzeugt, die Verteidiger verstehen müssen.

Das unmittelbare Problem ist eine Klasse von Angriffen auf QPACK, den Header-Komprimierungsmechanismus von HTTP/3. FoxIO berichtet, dass ein nicht authentifizierter Remote-Client einen HTTP/3-Server dazu bringen kann, Dutzende bis Tausende Male mehr Speicher zu reservieren als durch den gesendeten Datenverkehr übertragen wird. Diese alarmierende Asymmetrie ist jedoch weniger wichtig als die übergeordnete Erkenntnis: Moderne Protokolle können nicht nur den Netzwerkverkehr verstärken, sondern auch den Verarbeitungsaufwand, den Speicherdruck und die betriebliche Komplexität.

Eine separate Studie aus dem Jahr 2026 verdeutlicht dasselbe Problem an der Infrastrukturgrenze. Forscher fanden Schwachstellen bei der Umwandlung von HTTP/3 in HTTP/1.1 bei sechs großen CDN-Anbietern. In ihrer Untersuchung waren alle sechs für eine Variante der Bandbreitenverstärkung und fünf für eine Variante der Verbindungsverstärkung anfällig. Die Forscher identifizierten 42.330 Subdomains als potenziell gefährdet. Laut der Studie hatten zwei CDN-Anbieter Schwachstellen eingeräumt, Bug-Bounties vergeben und Gegenmaßnahmen umgesetzt. Das sind Forschungsergebnisse und kein Beleg dafür, dass heute jede HTTP/3-Installation gefährdet ist. Sie zeigen jedoch, wie leicht ein Feature zur Belastung werden kann, wenn Systeme auf beiden Seiten eines Gateways mit unterschiedlichen Versionen des Webs sprechen.

HTTP/3 hat die Komplexität nicht beseitigt, sondern an schwierigere Stellen verlagert

Der Reiz von HTTP/3 ist real. Es läuft über QUIC statt über TCP, verbindet Transport- und TLS-bezogene Funktionen und unterstützt multiplexierte Datenströme. Dieses Design soll Transportprobleme wie Head-of-Line-Blocking beheben und die Verbindungs-Latenz reduzieren. Cloudflare zufolge erreichte HTTP/3 im Mai 2023 einen Anteil von 28 Prozent am untersuchten Datenverkehr, nachdem dieser im Mai 2022 noch knapp über 23 Prozent gelegen hatte.

Doch Leistung ist für sich genommen keine Sicherheitseigenschaft. QUIC läuft üblicherweise im User Space über UDP. Dadurch verändert sich, was herkömmliche Netzwerk-Kontrollen sehen und verwalten können. Ohne QUIC- und TLS-Terminierung können zwischengeschaltete Geräte HTTP/3-Anfragen, Header oder die Anwendungslogik nicht vollständig untersuchen. IP-Adressen, Ports, Paket-Raten, Datagrammgrößen und Datenflussmuster können sie weiterhin nutzen. Die gewohnte Sichtbarkeit eines TCP-zentrierten Protokollstapels reicht jedoch nicht mehr aus.

QPACK fügt eine weitere Zustandsebene hinzu. Komprimierung ist wertvoll, weil wiederkehrende Header nicht vollständig übertragen werden müssen. Komprimierte Darstellungen müssen jedoch anhand gemeinsam genutzter Strukturen wie dynamischer Tabellen dekodiert werden. Wenn eine Implementierung blockierte oder speziell präparierte Datenströme schlecht verarbeitet, kann eine kleine Eingabe einen unverhältnismäßig hohen Speicher- oder Verarbeitungsaufwand verursachen. Unserer Ansicht nach handelt es sich dabei nicht um eine zufällige Fehlerklasse. Es ist die vorhersehbare Sicherheitskosten eines effizienteren Protokolls, das auf zustandsbehaftete Mechanismen setzt.

Die gefährlichste Lücke klafft zwischen Protokolldesign und Einsatzrealität

Die CDN-Forschung ist besonders wichtig, weil der Angriff nicht allein von einem Fehler in einer einzelnen Serverimplementierung abhängt. Er nutzt eine Diskrepanz aus: Eine effiziente HTTP/3-Verbindung, die bei einem CDN eingeht, kann in weniger effizienten HTTP/1.1-Datenverkehr zum Ursprungssystem übersetzt werden. Der Edge versteht ein Leistungsmodell, während das Backend ein anderes verarbeiten muss.

Das sollte die Art und Weise verändern, wie Organisationen Protokoll-Upgrades bewerten. „Wir haben HTTP/3 am Edge aktiviert“ ist keine vollständige Beschreibung der Architektur. Betreiber müssen auch fragen, was zwischen Edge und Ursprungssystem geschieht, wo Header erweitert werden, wie die Lebensdauer von Verbindungen gesteuert wird und welche Komponente für Ratenbegrenzungen zuständig ist. Eine sichere Eingangstür kann weiterhin zum Verstärker werden, wenn die Übersetzungsschicht als bloße Infrastruktur statt als Angriffsfläche behandelt wird.

Dasselbe Prinzip gilt für QPACK. Ein Server kann problemlos erreichbar sein und HTTP/3 korrekt aushandeln, während er bei ungewöhnlichen Komprimierungsfolgen dennoch gefährliches Ressourcenverhalten zeigt. Sicherheitstests müssen deshalb mehr messen als nur die Zurückweisung fehlerhafter Eingaben. Sie müssen erfassen, wie viel Speicher, CPU, Verbindungskapazität und nachgelagerter Datenverkehr bis zur Zurückweisung verbraucht werden.

„HTTP/3 einfach abschalten“ ist eine Gegenmaßnahme, keine Strategie

Betreiber haben eine drastische Option: UDP-Port 443 blockieren und HTTP/3 während eines Vorfalls vollständig abschalten. Damit wird HTTP/3 jedoch auch für legitime Nutzer entfernt. Gezieltere Kontrollen – Ratenbegrenzungen, Filter für fehlerhafte Pakete, Versionsvalidierung, Adressvalidierung und Gegenmaßnahmen bei vorgelagerten Anbietern – können die Gefährdung reduzieren, ohne das Protokoll allen Nutzern zu entziehen.

Dieser Unterschied ist wichtig, weil das Deaktivieren eines Protokolls architektonische Schwächen verdecken kann, anstatt sie zu beheben. Wenn das Ursprungssystem übersetzten Datenverkehr nicht verkraftet oder eine Implementierung den QPACK-bezogenen Speicherverbrauch nicht begrenzen kann, kann dieselbe Schwäche bei einer erneuten Aktivierung von HTTP/3 wieder auftreten. Die richtige Reaktion ist keine dauerhafte Scheu vor QUIC, sondern eine disziplinierte Einführung, die Ressourcenerschöpfung als grundlegendes Korrektheitsproblem behandelt.

Die jüngsten Offenlegungen sollten außerdem von vereinfachten Einstufungen des Schweregrads abhalten. Ein Angriff muss nicht trivial sein, um relevant zu werden. Eine Technik, die Spezialwissen erfordert, kann für Angreifer dennoch wertvoll sein, wenn sie gemeinsam genutzte Infrastruktur betrifft, viele Mandanten beeinträchtigt oder Verteidiger zu einer kostspieligen Alles-oder-nichts-Reaktion zwingt. Umgekehrt bedeutet eine hohe theoretische Verstärkungsrate nicht automatisch eine allgemeine Kompromittierung. Die Gefährdung hängt von Implementierung, Konfiguration, Datenverkehrskontrollen und dem genauen Pfad zwischen Client, CDN und Ursprungssystem ab.

Unser Urteil ist eindeutig: HTTP/3 bleibt den Einsatz wert, aber nur dort, wo sich seine gesamte Ressourcenkette überwachen und testen lässt. Organisationen sollten jede QUIC- und HTTP/3-Implementierung erfassen, QPACK- und Datenstromlimits überprüfen, die Übersetzung zwischen CDN und Ursprungssystem testen und sicherstellen, dass ihre Überwachung UDP-Floods von Angriffen auf der Anwendungsebene unterscheiden kann. Erfolgreich werden nicht die Teams sein, die das neueste Protokoll zuerst einsetzen. Erfolgreich werden die Teams sein, die detailliert erklären können, was das Protokoll ihre Infrastruktur tun lässt, wenn die Eingaben bösartig sind.