10. Sicherheitsüberlegungen (Security Considerations)

Die Sicherheitsüberlegungen von HTTP/3 sollten mit denen von HTTP/2 mit TLS vergleichbar sein. Viele der Überlegungen aus Abschnitt 10 von [HTTP/2] gelten jedoch für [QUIC-TRANSPORT] und werden in diesem Dokument diskutiert.

10.1. Serverautorität (Server Authority)

HTTP/3 stützt sich auf die HTTP-Definition von Autorität. Die Sicherheitsüberlegungen zur Feststellung der Autorität werden in Abschnitt 17.1 von [HTTP] diskutiert.

10.2. Protokollübergreifende Angriffe (Cross-Protocol Attacks)

Die Verwendung von ALPN in den TLS- und QUIC-Handshakes etabliert das Zielanwendungsprotokoll, bevor Bytes der Anwendungsschicht verarbeitet werden. Dies stellt sicher, dass Endpunkte starke Zusicherungen haben, dass Peers dasselbe Protokoll verwenden.

Dies garantiert keinen Schutz vor allen protokollübergreifenden Angriffen. Abschnitt 21.5 von [QUIC-TRANSPORT] beschreibt einige Möglichkeiten, wie der Klartext von QUIC-Paketen verwendet werden kann, um Anfragefälschungen gegen Endpunkte durchzuführen, die keine authentifizierten Transporte verwenden.

10.3. Vermittler-Kapselungsangriffe (Intermediary-Encapsulation Attacks)

Die HTTP/3-Feldcodierung erlaubt den Ausdruck von Namen, die in der von HTTP verwendeten Syntax keine gültigen Feldnamen sind (Abschnitt 5.1 von [HTTP]). Anfragen oder Antworten mit ungültigen Feldnamen MÜSSEN (MUST) als fehlerhaft behandelt werden.

Ebenso kann HTTP/3 Feldwerte transportieren, die nicht gültig sind. Während die meisten Werte, die codiert werden können, die Feldanalyse nicht verändern, könnten Wagenrücklauf (ASCII 0x0d), Zeilenvorschub (ASCII 0x0a) und das Nullzeichen (ASCII 0x00) von einem Angreifer ausgenutzt werden, wenn sie wörtlich übersetzt werden.

10.4. Cachefähigkeit gepushter Antworten (Cacheability of Pushed Responses)

Gepushte Antworten haben keine explizite Anfrage vom Client; die Anfrage wird vom Server im PUSH_PROMISE-Frame bereitgestellt.

Wenn mehrere Mieter Platz auf demselben Server teilen, MUSS (MUST) dieser Server sicherstellen, dass Mieter nicht in der Lage sind, Darstellungen von Ressourcen zu pushen, über die sie keine Autorität haben.

10.5. Überlegungen zu Denial-of-Service (Denial-of-Service Considerations)

Eine HTTP/3-Verbindung kann ein größeres Engagement von Ressourcen erfordern, um zu funktionieren, als eine HTTP/1.1- oder HTTP/2-Verbindung.

Die Fähigkeit, undefinierte Protokollelemente zu senden, die der Peer ignorieren muss, kann missbraucht werden, um einen Peer zu veranlassen, zusätzliche Verarbeitungszeit aufzuwenden.

Ein Endpunkt, der solches Verhalten nicht überwacht, setzt sich dem Risiko eines Denial-of-Service-Angriffs aus. Implementierungen SOLLTEN (SHOULD) die Verwendung dieser Funktionen verfolgen und Grenzen für ihre Verwendung setzen.

10.5.1. Grenzen für Feldabschnittsgröße (Limits on Field Section Size)

Ein großer Feldabschnitt (Abschnitt 4.1) kann dazu führen, dass eine Implementierung eine große Menge an Zustand festlegt. Ein Endpunkt kann die Einstellung SETTINGS_MAX_FIELD_SECTION_SIZE (Abschnitt 4.2.2) verwenden, um Peers über Grenzen zu informieren, die für die Größe von Feldabschnitten gelten könnten.

10.5.2. CONNECT-Probleme (CONNECT Issues)

Die CONNECT-Methode kann verwendet werden, um eine unverhältnismäßige Last auf einem Proxy zu erzeugen, da die Stream-Erstellung im Vergleich zur Erstellung und Wartung einer TCP-Verbindung relativ kostengünstig ist.

10.6. Verwendung von Komprimierung (Use of Compression)

Komprimierung kann es einem Angreifer ermöglichen, geheime Daten wiederherzustellen, wenn sie im selben Kontext wie vom Angreifer kontrollierte Daten komprimiert werden. HTTP/3 aktiviert die Komprimierung von Feldern (Abschnitt 4.2).

Implementierungen, die auf einem sicheren Kanal kommunizieren, DÜRFEN NICHT (MUST NOT) Inhalte komprimieren, die sowohl vertrauliche als auch vom Angreifer kontrollierte Daten enthalten, es sei denn, für jede Datenquelle werden separate Komprimierungskontexte verwendet.

10.7. Padding und Verkehrsanalyse (Padding and Traffic Analysis)

Padding kann verwendet werden, um die genaue Größe des Frame-Inhalts zu verschleiern und wird bereitgestellt, um spezifische Angriffe innerhalb von HTTP abzuschwächen.

10.8. Frame-Analyse (Frame Parsing)

Mehrere Protokollelemente enthalten verschachtelte Längenelemente. Eine Implementierung MUSS (MUST) sicherstellen, dass die Länge eines Frames genau mit der Länge der darin enthaltenen Felder übereinstimmt.

10.9. Frühe Daten (Early Data)

Die Verwendung von 0-RTT mit HTTP/3 schafft eine Exposition gegenüber Replay-Angriffen. Die Anti-Replay-Gegenmaßnahmen in [HTTP-REPLAY] MÜSSEN (MUST) angewendet werden, wenn HTTP/3 mit 0-RTT verwendet wird.

10.10. Migration

Bestimmte HTTP-Implementierungen verwenden die Client-Adresse für Protokollierungs- oder Zugangskontrollzwecke. Da sich die Adresse eines QUIC-Clients während einer Verbindung ändern kann, müssen solche Implementierungen entweder die aktuelle Adresse des Clients aktiv abrufen oder explizit akzeptieren, dass sich die ursprüngliche Adresse ändern kann.

10.11. Datenschutzüberlegungen (Privacy Considerations)

Mehrere Merkmale von HTTP/3 bieten einem Beobachter die Möglichkeit, Aktionen eines einzelnen Clients oder Servers im Laufe der Zeit zu korrelieren. Dazu gehören der Wert von Einstellungen, das Timing von Reaktionen auf Reize und die Handhabung von Funktionen, die durch Einstellungen gesteuert werden.

Die Präferenz von HTTP/3 für die Verwendung einer einzelnen QUIC-Verbindung ermöglicht die Korrelation der Aktivität eines Benutzers auf einer Site.