Zusammenfassung

  • Rapid Reset öffnete HTTP/2-Streams und beendete sie fast sofort mit RST_STREAM. Der Stream verschwand aus dem Gleichzeitigkeitszähler, während Proxy oder Anwendung die angestoßene Arbeit noch ausführen konnten.
  • Wirksame Abwehr bewertete deshalb das Verhalten über die gesamte Verbindung: ungewöhnliche Folgen erkennen, GOAWAY senden oder die Verbindung schließen, ohne legitimen Abbruch generell abzuschaffen.

Im Protokoll beendet, im System noch lebendig

HTTP/2 bündelt viele Anfragen auf einer Verbindung. Ein Client darf einen Stream mit RST_STREAM abbrechen, wenn eine Navigation beendet, eine Suche überholt oder ein Ergebnis nicht mehr benötigt wird. CVE-2023-44487 entstand aus dem Zusammenspiel dieser nützlichen Eigenschaften, nicht aus einer unbekannten Erweiterung.

Die Spezifikation begrenzt gleichzeitig aktive Streams. Sobald ein Stream geschlossen ist, belastet er dieses Budget nicht mehr. Beim Angriff folgte auf HEADERS nahezu sofort ein Reset. Der freigewordene Platz ließ sich sofort wiederverwenden. Aus Sicht der Zustandsmaschine war der Stream erledigt; in Routing, Dekompression, Protokollierung, Anwendung oder Datenbank konnte seine Arbeit gerade erst beginnen.

Die wirkliche Schuld stand somit nicht im Zähler offener Streams. Sie bestand aus begonnener, noch nicht abgebrochener oder abgeschlossener Arbeit. Rapid Reset ließ eine Verbindung neue Schuld schneller erzeugen, als die Infrastruktur sie tilgen konnte.

Drei Anbieter, getrennte Messpunkte

Google meldete einen Angriff mit mehr als 398 Millionen Anfragen pro Sekunde. Cloudflare berichtete von mehr als 201 Millionen Anfragen pro Sekunde aus einem Botnetz von geschätzt rund 20.000 Maschinen. AWS beschrieb Ereignisse mit mehr als 155 Millionen Anfragen pro Sekunde am 28. und 29. August.

Diese Spitzen dürfen nicht addiert werden. Sie stammen aus unterschiedlichen Ereignissen und Beobachtungsflächen. Gemeinsam zeigen sie dennoch eine neue Größenordnung: Durch wiederverwendete Verbindungen und eine zu früh vergessene Arbeitslast stieg die Wirkung jedes kompromittierten Geräts.

Ebenso wenig belegen die Berichte, dass jede HTTP/2-Implementierung gleich anfällig war. Terminierung, Warteschlangen, Proxyketten und Abbruchlogik unterschieden sich. Die Lektion ist weltweit relevant, der genaue Fehlerpfad bleibt lokal.

Ein Zähler für die falsche Frage

Ein Gleichzeitigkeitslimit fragt: Wie viele Streams sind jetzt offen? Die entscheidenden Fragen lauten jedoch: Wie viele Streams hat diese Verbindung insgesamt erzeugt? Wie viele wurden sofort zurückgesetzt? Welche Arbeit überlebt den Reset? Wann werden CPU, Speicher und Backendkapazität tatsächlich frei?

Cloudflares Erfahrung mit einer Absenkung von MAX_CONCURRENT_STREAMS auf 64 zeigt die Nebenwirkungen einer eindimensionalen Antwort. Einige legitime Clients gingen vor Empfang der Servereinstellungen optimistisch von 100 Streams aus. Serverseitige Resets für den Überschuss trafen auf frühere resetbasierte Schutzregeln und verursachten Seitenfehler. Cloudflare stellte den Wert 100 wieder her.

Damit sind Parallelitätsgrenzen nicht nutzlos. Sie sind nur kein vollständiges Kostenmodell. Eine Maßnahme muss unter realem Verkehr beweisen, dass sie normalen Abbruch erhält und zugleich verhindert, dass dieselbe Verbindung fortlaufend neue Arbeit erzeugt.

Die Verbindung wird rechenschaftspflichtig

Google beschrieb eine schnelle Erkennung des Musters auf Verbindungsebene, gefolgt von GOAWAY oder dem Schließen der Verbindung. Cloudflare ergänzte Erkennung clientseitiger Resets und Arbeiten an Warteschlangen, Scheduling, Abbruch und Protokollierung; eine frühere Abwehr saß im TLS-Proxy. Die gemeinsame Idee lautet: Ein einzelner Reset kann legitim sein, seine kumulierte Folge kann Missbrauch belegen.

Wird die Verbindung geschlossen, verliert der Angreifer den billigen Kanal für immer neue Streams. Eine neue Verbindung kostet Zustand und kann erneut klassifiziert werden. Normale Nutzer behalten gelegentlichen Abbruch. Nicht die Funktion wird verboten, sondern ihre unbegrenzte Wiederholung bei wachsender Restarbeit.

Das entspricht dem Vorrang des laufenden Codes. Die gemeinsame Spezifikation liefert verständliche Zustände. Die konkrete Implementierung besitzt Warteschlangen, CPU, Speicher und Abhängigkeiten. Sie muss daher lokal entscheiden dürfen, wann eine Verbindung ihre Ressourcen gefährdet.

Gemeinsame Semantik, lokale Kosten

RFC 9113 beschreibt Streamzustände, RST_STREAM, GOAWAY und Parallelitätsgrenzen. Sie verspricht nicht, dass ein Reset augenblicklich jede interne Wirkung rückgängig macht. Ob Arbeit noch in einem Proxy, Dienst oder einer Datenbank weiterläuft, kann nur der konkrete Pfad beantworten.

Ein späterer individueller Internet-Draft schlug kumulative Stream-Guthaben vor. Die Diagnose ist nützlich: Auch schnell geschlossene Streams müssen über die Lebensdauer der Verbindung in die Rechnung eingehen. Der Entwurf ist jedoch weder verabschiedeter Standard noch IETF-Konsens. Er ist eine Gestaltungsoption.

Eine minimale Spezifikation sollte interoperable Bedeutung sichern. Lokale Systeme sollten tatsächliche Kosten messen und Kooperation beenden können. Wer beides vermischt, erwartet entweder von der Norm Kontrolle über unsichtbare Warteschlangen oder führt pauschale Abwehr ein, die reale Clients beschädigt.

Was ein belastbares Patch-Inventar enthält

„Gepatcht“ ist keine ausreichende Bestandsaufnahme. Betreiber müssen wissen, wo HTTP/2 terminiert, wohin Anfragen weitergereicht werden und an welcher Stelle ein Reset die Arbeit wirklich beendet. Ein aktualisierter Load Balancer hilft wenig, wenn ein nachgelagerter Proxy unbegrenzt verwaiste Arbeit annimmt.

Für jeden Terminierungspunkt gehören Versionsstand, kumulative Streamrate, Verhältnis von Öffnungen zu Resets, nach Reset verbleibende Arbeit und die Instanz mit Schließhoheit zusammen. Tests müssen sowohl Angriffsmuster als auch legitime Abbrüche enthalten. Eine Abwehr, die beides fallen lässt, ist keine präzise Abwehr.

Grenzen der Belege

Die öffentlichen Details stammen vor allem von großen Anbietern über ihre eigenen Systeme. Sie stützen Mechanismus, gemeldete Spitzen und mehrere operative Gegenmaßnahmen. Sie beziffern nicht, welcher Anteil des Internets verwundbar war, und beweisen keine universelle Parametrisierung. Auch machen sie Abbruch nicht grundsätzlich verdächtig.

Die belastbare Schlussfolgerung ist enger: Das Ende eines Protokollobjekts ist nicht automatisch das Ende seiner Kosten. Multiplexsysteme müssen Restarbeit dem Kanal zurechnen, der sie erzeugt.

Quellen

  1. Cloudflare, „HTTP/2 Rapid Reset: deconstructing the record-breaking attack“: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
  2. Google Cloud, „How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack“: https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack?hl=en
  3. Google Cloud, „Google mitigated the largest DDoS attack to date“: https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps
  4. AWS Security Blog, „How AWS protects customers from DDoS events“: https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/
  5. AWS Security Bulletin AWS-2023-011: https://aws.amazon.com/security/security-bulletins/AWS-2023-011/
  6. IETF, RFC 9113, „HTTP/2“: https://www.rfc-editor.org/rfc/rfc9113.html
  7. IETF Internet-Draft, „Cumulative Stream Limits for HTTP/2“: https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-h2-stream-limits-00
  8. Heng Lu, „Running-Code Primary“: https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  9. Heng Lu, „Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption“: https://heng.lu/minimum-initial-specification-localized-future-decision-and-voluntary-adoption-for-internet-coordination-systems/