10. Sicherheitsbetrachtungen
Die Sicherheitsbetrachtungen für HTTP/3 sollten denen von HTTP/2 mit TLS entsprechen. Viele der Betrachtungen aus Abschnitt 10 von [HTTP/2] gelten jedoch für [QUIC-TRANSPORT] und werden dort behandelt.
10.1. Serverautorität
HTTP/3 stützt sich auf die Definition von Autorität in HTTP. Sicherheitsbetrachtungen zur Herstellung von Autorität werden in Abschnitt 17.1 von [HTTP] behandelt.
10.2. Protokollübergreifende Angriffe
Die Verwendung von ALPN im TLS- und QUIC-Handshake legt das beabsichtigte Anwendungsprotokoll fest, bevor Bytes der Anwendungsschicht verarbeitet werden. Dies gibt Endpunkten eine starke Zusicherung, dass der Peer dasselbe Protokoll verwendet.
Dies garantiert keinen Schutz vor allen protokollübergreifenden Angriffen. Abschnitt 21.5 von [QUIC-TRANSPORT] beschreibt einige Möglichkeiten, wie Klartext aus QUIC-Paketen für Anfragenfälschungen gegen Endpunkte ohne authentifizierten Transport verwendet werden kann.
10.3. Angriffe durch Kapselung über Zwischenstellen
Die Feldkodierung von HTTP/3 erlaubt die Darstellung von Feldnamen, die in der von HTTP verwendeten Syntax ungültig sind, siehe Abschnitt 5.1 von [HTTP]. Anfragen oder Antworten mit ungültigen Feldnamen müssen als fehlerhaft behandelt werden.
Ebenso kann HTTP/3 ungültige Feldwerte übertragen. Die meisten kodierbaren Werte verändern zwar die Feldanalyse nicht, doch Wagenrücklauf (ASCII 0x0d), Zeilenvorschub (ASCII 0x0a) und das Nullzeichen (ASCII 0x00) können von Angreifern ausgenutzt werden, wenn sie wortgetreu weitergegeben werden.
10.4. Zwischenspeicherbarkeit gepushter Antworten
Für gepushte Antworten gibt es keine explizite Anfrage des Clients; die Anfrage wird vom Server in einem PUSH_PROMISE-Frame bereitgestellt.
Wenn mehrere Mandanten Ressourcen auf demselben Server teilen, muss der Server sicherstellen, dass Mandanten keine Repräsentationen von Ressourcen pushen können, für die sie nicht berechtigt sind.
10.5. Betrachtungen zu Dienstverweigerung
Der Betrieb einer HTTP/3-Verbindung kann im Vergleich zu einer HTTP/1.1- oder HTTP/2-Verbindung ein größeres Ressourcenengagement erfordern.
Die Fähigkeit, nicht definierte Protokollelemente zu senden, die der Peer ignorieren muss, kann missbraucht werden und beim Peer zusätzlichen Verarbeitungsaufwand verursachen.
Endpunkte, die ein solches Verhalten nicht überwachen, setzen sich dem Risiko von Dienstverweigerungsangriffen aus. Implementierungen SOLLTEN die Nutzung dieser Funktionen nachverfolgen und ihre Nutzung begrenzen.
10.5.1. Begrenzungen der Feldabschnittsgröße
Große Feldabschnitte (Abschnitt 4.1) können dazu führen, dass eine Implementierung erhebliche Zustandsinformationen vorhalten muss. Ein Endpunkt kann die Einstellung SETTINGS_MAX_FIELD_SECTION_SIZE (Abschnitt 4.2.2) verwenden, um dem Peer Grenzen mitzuteilen, die für die Größe von Feldabschnitten gelten können.
10.5.2. CONNECT-Probleme
Die Methode CONNECT kann eine unverhältnismäßige Last auf einem Proxy erzeugen, weil das Erzeugen von Streams im Vergleich zum Erzeugen und Aufrechterhalten von TCP-Verbindungen relativ preiswert ist.
10.6. Verwendung von Kompression
Wenn Kompression vertrauliche Daten im selben Kontext wie von einem Angreifer kontrollierte Daten komprimiert, kann sie einem Angreifer die Wiederherstellung vertraulicher Daten ermöglichen. HTTP/3 aktiviert Feldkompression, siehe Abschnitt 4.2.
Implementierungen, die über einen sicheren Kanal kommunizieren, dürfen Inhalte mit vertraulichen und von Angreifern kontrollierten Daten nicht komprimieren, es sei denn, für jede Datenquelle wird ein separater Kompressionskontext verwendet.
10.7. Padding und Verkehrsanalyse
Padding kann verwendet werden, um die genaue Größe des Frame-Inhalts zu verschleiern und bestimmte Angriffe innerhalb von HTTP abzumildern.
10.8. Frame-Analyse
Mehrere Protokollelemente enthalten verschachtelte Längenelemente. Implementierungen müssen sicherstellen, dass die Länge eines Frames genau der Länge der darin enthaltenen Felder entspricht.
10.9. Frühe Daten
Die Verwendung von 0-RTT mit HTTP/3 birgt das Risiko von Wiederholungsangriffen. Die in [HTTP-REPLAY] beschriebenen Maßnahmen gegen Wiederholungsangriffe müssen bei der Verwendung von HTTP/3 mit 0-RTT angewendet werden.
10.10. Migration
Einige HTTP-Implementierungen verwenden die Clientadresse für Protokollierung oder Zugriffskontrolle. Da sich die Adresse eines QUIC-Clients während einer Verbindung ändern kann, müssen solche Implementierungen die aktuelle Clientadresse aktiv abrufen oder ausdrücklich akzeptieren, dass sich die ursprüngliche Adresse ändern kann.
10.11. Datenschutzbetrachtungen
Mehrere Eigenschaften von HTTP/3 ermöglichen Beobachtern, Vorgänge einzelner Clients oder Server im Zeitverlauf miteinander zu verknüpfen. Dazu gehören Werte von Einstellungen, Reaktionszeiten auf Stimuli und die Behandlung von Funktionen, die durch Einstellungen gesteuert werden.
Die Bevorzugung einer einzelnen QUIC-Verbindung durch HTTP/3 ermöglicht es, die Aktivitäten eines Benutzers auf einer Website miteinander zu verknüpfen.