10. Security Considerations (Sicherheitsüberlegungen)
10.1. Server Authority (Server-Autorität)
HTTP/2 verlässt sich auf die HTTP/1.1-Definition von Autorität, um zu bestimmen, ob ein Server autoritativ ist, um eine bestimmte Antwort bereitzustellen (siehe Abschnitt 17.1 von [HTTP]). Dies basiert auf der lokalen Namensauflösung für das "https"-Schema und der authentifizierten Server-Identität für das "https"-Schema (wie in Abschnitt 4.2.2 von [HTTP] definiert). Alternative Dienste ([ALT-SVC]), die zur Feststellung der Autorität verwendet werden, können erhebliche zusätzliche Komplexität einführen.
10.2. Cross-Protocol Attacks (Protokollübergreifende Angriffe)
In TLS verwendet HTTP/2 die Application-Layer Protocol Negotiation (ALPN)-Erweiterung [TLS-ALPN], um die Verwendung des Protokolls auszuhandeln. Dies erzeugt ein positives Signal, dass der Server HTTP/2 unterstützt, und reduziert die Exposition von HTTP/2 gegenüber protokollübergreifenden Angriffen.
In Klartext oder wenn ALPN nicht in TLS verwendet wird, könnte die HTTP/2-Client-Verbindungspräambel (Abschnitt 3.4) mit anderen Protokollen verwechselt werden. Die HTTP/2-Verbindungspräambel ist so konzipiert, dass diese Möglichkeit minimiert wird, indem eine Sequenz gewählt wird, die unwahrscheinlich ein gültiger Start für andere Protokolle ist.
Jedes Protokoll, das für einen HTTP/2-Endpunkt zugänglich ist, kann verwendet werden, um das zu etablieren, was als gültige HTTP/2-Verbindung erscheint. Aus diesem Grund muss die von einem serverseitigen Endpunkt empfangene Verbindungspräambel für das Protokoll gültig sein, um einen protokollübergreifenden Angriff zu bilden.
Die Client-Verbindungspräambel (Abschnitt 3.4) ist nicht ausreichend, um sicherzustellen, dass das Protokoll nicht verwechselt wird, aber sie bietet einen gewissen Schutz. HTTP/2-Client-Implementierungen müssen möglicherweise auch zusätzliche Überprüfungen durchführen, bevor HTTP-Semantik angewendet wird. Insbesondere müssen Clients sicherstellen, dass die initiale Antwort eine legitime Antwort auf eine Nachricht ist, die der Client gesendet hat.
Ein Server könnte einen Client angreifen, indem er eine Anfrage an einen Zielserver sendet, die der Client an einen anderen Server senden wollte. Wenn der empfangende Server ein anderes HTTP-Schema als HTTP/2 unterstützt, kann der Server eine an einen anderen Server gesendete Anfrage lesen und zurückgeben. Ein Angreifer kann die Antwort abfangen und modifizieren, die der Client empfängt, was dazu führt, dass der Client Informationen in der Antwort mit einer Antwort auf eine Anfrage assoziiert, zu der sie nicht gehört.
10.3. Intermediary Encapsulation Attacks (Vermittler-Kapselungsangriffe)
Die HTTP/2-Feldcodierung ermöglicht den Ausdruck von Feldnamen und -werten, die keine gültigen Feldnamen und -werte in HTTP/1.1 sind oder die in HTTP/1.1 nicht ausgedrückt werden können. Anfragen oder Antworten, die ungültige Feldnamen oder -werte enthalten, machen Implementierungen, die unzureichende Validierung von Feldnamen und -werten durchführen, anfällig. Ein Angreifer könnte in der Lage sein, einen Vermittler zu verwenden, um eine Anfrage oder Antwort so zu kapseln, dass eine ungültige Nachricht gültig erscheint.
Ein HTTP/2-zu-HTTP/1.1-Übersetzer, der Anfragen und Antworten nicht vollständig validiert, könnte einem böswilligen Client erlauben, Feldwerte zu schmuggeln oder Felder mit irreführenden Feldnamen zu erstellen.
10.4. Cacheability of Pushed Responses (Cachefähigkeit gepushter Antworten)
Gepushte Antworten haben keine explizite Anfrage von einem Client; die Anfrage wird vom Server in einem PUSH_PROMISE-Frame bereitgestellt.
Das Caching gepushter Antworten kann problematisch sein. Abhängig von den Informationen, die zur Herstellung der Verbindung verwendet werden, könnte eine gepushte Antwort versehentlich einem neuen Client zur Verfügung gestellt werden, der die Verbindung teilt, aber unbeabsichtigt die Ressource angefordert hat.
Beispielsweise könnte im Fall der Verwendung von TLS zur Authentifizierung ein böswilliger Client eine gepushte Antwort über sensible Informationen eines authentifizierten Benutzers unter Verwendung derselben Verbindung erhalten.
Server MÜSSEN nur Werte einschließen, die in Anfragen cachebar sind, die gepusht werden (siehe Abschnitt 9.2.3 von [HTTP]); gepushte Anfragen enthalten keine Werte für Anfrageinhalte. Gepushte Antworten werden als nicht cachebar gekennzeichnet, indem ein Cache-Control-Header-Feld mit der no-cache- oder private-Cache-Antwortdirektive eingefügt wird (siehe Abschnitt 5.2.2.4 von [HTTP-CACHING]).
Wenn dieselbe gepushte Antwort für Antworten bereitgestellt werden kann, die sowohl cachebar als auch nicht cachebar sind, könnten Clients die gepushte Antwort fälschlicherweise unter Verwendung der cachebaren Antwort cachen.
Daher SOLLTEN Server ein Cache-Control-Header-Feld mit dem Wert "no-cache" im HEADERS-Frame eines gepushten Streams einschließen, es sei denn, es gibt ein explizites Signal, das anzeigt, dass der Client die Antwort cached.
10.5. Denial-of-Service Considerations (Denial-of-Service-Überlegungen)
Die Verwendung von HTTP/2 führt mehrere neue Denial-of-Service (DoS)-Möglichkeiten ein.
10.5.1. Limits on Field Section Size (Grenzen für die Feldabschnittsgröße)
Ein Feldabschnitt, der eine große Anzahl von Feldern oder lange Feldnamen oder -werte enthält, kann eine Implementierung dazu bringen, übermäßige Mengen an Speicher, CPU-Zeit oder beides zu verbrauchen.
Implementierungen SOLLTEN Grenzen für die Gesamtzahl und Größe der Feldzeilen festlegen, die sie akzeptieren, und die Gesamtzahl und Größe, die sie senden, wodurch die Gesamtgröße der Frames begrenzt wird, die einen Feldabschnitt umfassen. Server möchten möglicherweise eine Whitelist von Feldzeilen führen, und Clients möchten möglicherweise Feldzeilen ablehnen, aber beide SOLLTEN Grenzen protokollieren und berücksichtigen, die die Interoperabilität behindern könnten.
10.5.2. CONNECT Issues (CONNECT-Probleme)
Die CONNECT-Methode kann verwendet werden, um eine Verbindung für nicht vertrauenswürdige Ziele zu erstellen. Die TCP-Verbindung für CONNECT unterliegt keiner Kontrolle, und sie könnte versuchen, sich mit Endpunkten oder anderen Geräten zu verbinden, was eine Verbindungsflut erzeugt. Implementierungen SOLLTEN Grenzen für die Ziele festlegen, die als CONNECT-Ziele zulässig sind, und SOLLTEN diese Grenzen protokollieren.
10.5.3. Use of Compression (Verwendung von Kompression)
Die Kompression von Feldblöcken in HTTP/2 basiert auf Algorithmen und Zuständen, die von einem Angreifer verwendet werden können, um Denial of Service zu verursachen.
Ein Angreifer kann Anfragen mit sorgfältig erstellten Feldern senden, um einen Feldabschnitt zu erstellen, der große Mengen an Decoderressourcen erfordert. Dies kann durch Verwendung großer Mengen an Huffman-codierten Zeichenfolgen oder durch Durchführung vieler Aktualisierungen der dynamischen Tabelle erfolgen. Das sofortige Starten eines neuen Feldabschnitts nach Beendigung eines (z. B. leere DATA-Frames gefolgt von einem HEADERS-Frame) könnte auch verwendet werden, um verfügbare Decoderressourcen zu begrenzen.
Ähnliche Angriffe können gesendet werden, um den Feldabschnitts-Komprimierungszustand aggressiv zu nutzen, um Antworten zu erstellen, die große Mengen an Encoderressourcen erfordern.
Implementierungen SOLLTEN Grenzen für die Größe der Felder festlegen, die sie dekomprimieren.
10.5.4. Use of Flow Control (Verwendung der Flusskontrolle)
Die Flusskontrolle in HTTP/2 ermöglicht es einem Gegner, die Datenmenge zu begrenzen, die ein Peer senden kann. Die Implementierung von Fensteraktualisierungen oder die Verwaltung des Flusskontrollfensters könnte dazu führen, dass Streams kein verfügbares Fenster erhalten, was den Stream unfähig macht, Fortschritte zu machen.
10.5.5. Use of Settings (Verwendung von Einstellungen)
Ein SETTINGS-Frame kann verwendet werden, um einen Peer dazu zu bringen, zusätzliche Verarbeitungszeit aufzuwenden. Dies könnte durch sinnloses Ändern von Einstellungen, Senden von SETTINGS-Frames ohne Änderung von Einstellungen oder häufiges Ändern von Einstellungen erfolgen.
Andere SETTINGS-Parameter, die Werte begrenzen, könnten verwendet werden, um Ressourcen zu verbrauchen, wie z. B. das Deaktivieren der dynamischen HPACK-Tabelle durch Festlegen eines sehr kleinen Werts für den SETTINGS_HEADER_TABLE_SIZE-Parameter.
Endpunkte SOLLTEN diese Verhaltensweisen erkennen und sie als Verbindungsfehler (Abschnitt 5.4.1) vom Typ ENHANCE_YOUR_CALM behandeln.
10.5.6. Use of Priorities (Verwendung von Prioritäten)
Prioritäten können verwendet werden, um einen Peer dazu zu bringen, übermäßige Ressourcen aufzuwenden. Häufige Änderungen des Prioritätsbaums oder unvernünftige Komplexität in Prioritätsbäumen können beide zu übermäßigem CPU-Verbrauch führen.
10.5.7. Use of HTTP/2 Without TLS (Verwendung von HTTP/2 ohne TLS)
HTTP/2 kann ohne Verwendung von TLS bereitgestellt werden. Dieser Modus hat dieselben Anfälligkeiten für bestimmte Angriffe wie HTTP/1.1. Implementierungen, die diesen Betriebsmodus verwenden, SOLLTEN für HTTP/1.1 anwendbare Schutzmaßnahmen anwenden.
Implementierungen müssen sich auch bewusst sein, dass viele HTTP/2-Funktionen ohne TLS anfälliger für Angriffe sein könnten. Insbesondere bedeutet das Fehlen von Vertraulichkeitsschutz und Integritätsschutz, die von TLS bereitgestellt werden, dass die Verschlüsselung oder Integrität der Daten gefährdet ist.
10.6. Use of Compression (Verwendung von Kompression)
Kompression kann es einem Angreifer ermöglichen, geheime Inhalte verschlüsselter Kommunikation wiederherzustellen, wenn diese Kompression mit Daten kombiniert wird, die von einem Angreifer kontrolliert werden, und geheimen Daten, deren Übertragungsgröße der Angreifer beobachten kann.
HTTP/2 bietet Kompression an mehreren Stellen: Feldblöcke verwenden HPACK [COMPRESSION], und die Inhalte von DATA-Frames können Inhaltscodierung verwenden (siehe Abschnitt 8.4.1 von [HTTP]).
HPACK ist so konzipiert, dass die Ausnutzung der Offenlegung von Geheimnissen erschwert wird; der Kompromiss zwischen Implementierungsauswahlen oder Anwendungsschutzmaßnahmen, die in einigen Fällen realisiert werden können, ist jedoch unvollkommen. Angriffe können die Wiederverwendung des Feldkomprimierungszustands über mehrere Anfragen hinweg ausnutzen. Implementierungen und Anwendungen können wählen, die Menge des über Anfragen hinweg verwendeten Komprimierungszustands zu begrenzen, um den Schutz zu verbessern, jedoch auf Kosten der Erhöhung der Nachrichtengröße.
Das Komprimieren der Inhalte von DATA-Frames wird im Allgemeinen als sicherer angesehen, da der Inhalt von DATA-Frames weniger wahrscheinlich mit von Angreifern kontrollierten Daten über mehrere Anfragen hinweg gemischt wird. Die Komprimierungs-Inhaltscodierung kombiniert jedoch Informationen aus verschiedenen Quellen. Obwohl die Verwendung eines anderen Ursprungsidentifikators Informationen aus verschiedenen Quellen unterscheidet (siehe Abschnitt 11.5 von [HTTP]), kann Kompression diese Trenner entfernen, wie in [BREACH] beschrieben.
Das Deaktivieren oder Begrenzen der Kompression für Inhaltscodierung wird im Allgemeinen als ausreichend angesehen, um diese Angriffe abzumildern, dies könnte jedoch nicht ausreichend sein, um alle Angriffe zu verhindern.
10.7. Use of Padding (Verwendung von Auffüllung)
Auffüllung kann verwendet werden, um die genaue Größe von Frame- und Nachrichteninhalten zu verschleiern. Auffüllung kann verwendet werden, um Angriffe abzumildern, die darauf beruhen, Verkehrsanalyse zu verwenden, um Informationen über Nachrichten abzuleiten, was für HTTP von besonderer Bedeutung ist, wo die Länge komprimierter Nachrichten Informationen über den enthaltenen Inhalt offenbaren könnte.
Ein Beispiel für die Verwendung von Auffüllung wäre das Senden einer großen Anzahl von HEADERS- und DATA-Frames mit Nutzlastgrößen, die zwischen den Frames variieren, um die genaue Größe einer Nachricht zu verschleiern. Die Verwendung von Auffüllung kann einige Angriffe reduzieren (z. B. [BREACH]).
Im Allgemeinen bedeutet die Existenz von Verkehrsanalyseangriffen, dass das Auffüllen auf eine feste Größe für jedes Feld oder jeden Frame nicht ausreicht, um Schutz zu bieten. Um effizient zu sein und ein gewisses Maß an Schutz zu bieten, SOLLTE die Auffüllung zufällig gewählt werden.
Auffüllung ist kein perfekter Schutz zum Verschleiern der Nachrichtengröße. Ein Angreifer könnte in der Lage sein, statistische Eigenschaften über die Größe von Nachrichten zu verwenden, was einem Angreifer ermöglichen könnte, die Länge von Nachrichten, ob aufgefüllt oder nicht, zu verwenden, um Informationen über den Inhalt mit einer gewissen Wahrscheinlichkeit abzuleiten.
10.8. Privacy Considerations (Datenschutzüberlegungen)
Mehrere Merkmale von HTTP/2 bieten einem Beobachter die Möglichkeit, eine Reihe von Anfragen zu korrelieren. Dazu gehören der Wert von Einstellungen, der Komprimierungskontext für Feldblöcke, die Verwaltung des Flusskontrollfensters und das Timing des Eintreffens von Nachrichten.
Insbesondere HTTP-Felder, die Informationen über die Benutzeridentität enthalten, können mit anderen Kommunikationen korreliert werden, auch wenn unterschiedliche Server verwendet werden.
HTTP/2 bietet keine spezifischen Mechanismen zum Schutz der Benutzerprivatsphäre.
Kapitel 10 abgeschlossen!
References
- [HTTP] RFC 9110
- [HTTP-CACHING] RFC 9111
- [TLS-ALPN] RFC 7301
- [ALT-SVC] RFC 7838
- [COMPRESSION] RFC 7541
- [BREACH] "BREACH: Reviving the CRIME Attack"