7. Sicherheitsüberlegungen (Security Considerations)

Dieser Abschnitt beschreibt potenzielle Bereiche sicherheitsrelevanter Bedenken bei HPACK:

• Verwendung von Komprimierung als längenbasiertes Orakel zur Überprüfung von Vermutungen über Geheimnisse, die in einen gemeinsamen Komprimierungskontext komprimiert werden.

• Denial of Service durch Erschöpfung der Verarbeitungs- oder Speicherkapazität eines Decoders.

7.1. Sondierung des dynamischen Tabellenzustands (Probing Dynamic Table State)

HPACK reduziert die Länge von Header-Feld-Kodierungen, indem es die Redundanz ausnutzt, die Protokollen wie HTTP innewohnt. Das ultimative Ziel hiervon ist es, die Menge an Daten zu reduzieren, die zum Senden von HTTP-Anfragen oder -Antworten erforderlich ist.

Der Komprimierungskontext, der zum Kodieren von Header-Feldern verwendet wird, kann von einem Angreifer sondiert werden, der sowohl Header-Felder definieren kann, die kodiert und übertragen werden sollen, als auch die Länge dieser Felder beobachten kann, sobald sie kodiert sind. Wenn ein Angreifer beides tun kann, kann er Anfragen adaptiv modifizieren, um Vermutungen über den Zustand der dynamischen Tabelle zu bestätigen. Wenn eine Vermutung in eine kürzere Länge komprimiert wird, kann der Angreifer die kodierte Länge beobachten und schlussfolgern, dass die Vermutung korrekt war.

Dies ist auch über das TLS-Protokoll (Transport Layer Security) möglich (siehe [TLS12]), da TLS zwar Vertraulichkeitsschutz für Inhalte bietet, aber nur eine begrenzte Menge an Schutz für die Länge dieses Inhalts bietet.

Hinweis: Auffüllschemata bieten nur begrenzten Schutz gegen einen Angreifer mit diesen Fähigkeiten und erfordern möglicherweise nur eine erhöhte Anzahl von Vermutungen, um die mit einer bestimmten Vermutung verbundene Länge zu erlernen. Auffüllschemata wirken auch direkt gegen die Komprimierung, indem sie die Anzahl der übertragenen Bits erhöhen.

Angriffe wie CRIME [CRIME] haben die Existenz dieser allgemeinen Angreiferfähigkeiten demonstriert. Der spezifische Angriff nutzte die Tatsache aus, dass DEFLATE [DEFLATE] Redundanz basierend auf Präfix-Übereinstimmung entfernt. Dies ermöglichte es dem Angreifer, Vermutungen ein Zeichen nach dem anderen zu bestätigen, wodurch ein Angriff mit exponentieller Zeit auf einen Angriff mit linearer Zeit reduziert wurde.

7.1.1. Anwendbarkeit auf HPACK und HTTP (Applicability to HPACK and HTTP)

HPACK mildert Angriffe nach dem Vorbild von CRIME [CRIME] ab, verhindert sie aber nicht vollständig, indem es eine Vermutung zwingt, mit einem gesamten Header-Feldwert übereinzustimmen, anstatt mit einzelnen Zeichen. Angreifer können nur lernen, ob eine Vermutung korrekt ist oder nicht, daher sind sie auf Brute-Force-Vermutungen für die Header-Feldwerte beschränkt.

Die Durchführbarkeit der Wiederherstellung spezifischer Header-Feldwerte hängt daher von der Entropie der Werte ab. Infolgedessen ist es unwahrscheinlich, dass Werte mit hoher Entropie erfolgreich wiederhergestellt werden. Werte mit niedriger Entropie bleiben jedoch anfällig.

Angriffe dieser Art sind jedes Mal möglich, wenn zwei sich gegenseitig misstrauende Entitäten Anfragen oder Antworten kontrollieren, die auf einer einzigen HTTP/2-Verbindung platziert werden. Wenn der gemeinsame HPACK-Kompressor es einer Entität erlaubt, Einträge zur dynamischen Tabelle hinzuzufügen, und der anderen, auf diese Einträge zuzugreifen, dann kann der Zustand der Tabelle erlernt werden.

Anfragen oder Antworten von sich gegenseitig misstrauenden Entitäten zu haben, tritt auf, wenn ein Vermittler entweder:

• Anfragen von mehreren Clients auf einer einzigen Verbindung zu einem Ursprungsserver sendet, oder

• Antworten von mehreren Ursprungsservern nimmt und diese auf einer gemeinsamen Verbindung zu einem Client platziert.

Webbrowser müssen auch davon ausgehen, dass Anfragen, die auf derselben Verbindung von verschiedenen Web-Ursprüngen (siehe [ORIGIN]) gestellt werden, von sich gegenseitig misstrauenden Entitäten gemacht werden.

7.1.2. Gegenmaßnahmen (Mitigation)

Benutzer von HPACK können Schritte unternehmen, um das Potenzial für das Sondieren der dynamischen Tabelle zu begrenzen, indem sie die Fähigkeit von sich gegenseitig misstrauenden Entitäten einschränken, Einträge zur dynamischen Tabelle hinzuzufügen und den Zustand der dynamischen Tabelle zu beobachten.

Die effektivste Gegenmaßnahme besteht darin, die gemeinsame Nutzung von Verbindungen oder Komprimierungskontexten zwischen Anfragen oder Antworten zu vermeiden, die nicht das Ergebnis von Aktionen desselben Ursprungs sind.

Für Vermittler bedeutet dies, dass Anfragen von verschiedenen Clients und Antworten von verschiedenen Ursprungsservern KEINEN gemeinsamen HPACK-Komprimierungskontext teilen DÜRFEN (MUST NOT).

Für Benutzeragenten bedeutet dies, dass Komprimierungskontexte für Anfragen an verschiedene Ursprünge getrennt werden MÜSSEN (MUST), die nicht bekanntermaßen unter gemeinsamer Kontrolle stehen.

7.1.3. Niemals indizierte Literale (Never-Indexed Literals)

Implementierungen können auch wählen, sensible Header-Felder zu schützen, indem sie diese nicht komprimieren und stattdessen ihren Wert als Literale kodieren.

Die Verweigerung der Generierung einer indizierten Darstellung für ein Header-Feld ist nur wirksam, wenn die Komprimierung auf allen Hops vermieden wird. Das niemals indizierte Literal-Bit (siehe Abschnitt 6.2.3) kann verwendet werden, um Vermittlern zu signalisieren, dass ein bestimmter Wert absichtlich als Literal gesendet wurde.

Ein Vermittler DARF ein Header-Feld, das die niemals indizierte Literaldarstellung verwendet, NICHT (MUST NOT) mit einer anderen Darstellung neu kodieren, die es indizieren würde. Wenn HPACK für die Neukodierung verwendet wird, kann stattdessen eine literale Darstellung ohne Indizierung (siehe Abschnitt 6.2.2) verwendet werden.

Die Wahl, eine niemals indizierte Literaldarstellung für ein Header-Feld zu verwenden, hängt von mehreren Faktoren ab. Da HPACK nicht vor dem Erraten eines gesamten Header-Feldwerts schützt, können kurze oder Werte mit niedriger Entropie von einem Gegner leichter wiederhergestellt werden. Daher könnte ein Encoder wählen, Werte mit niedriger Entropie nicht zu indizieren.

Ein Encoder könnte auch wählen, Werte für Header-Felder nicht zu indizieren, die als sehr wertvoll oder empfindlich für die Wiederherstellung angesehen werden, wie die Header-Felder Cookie oder Authorization.

7.2. Statische Huffman-Kodierung (Static Huffman Encoding)

Es ist derzeit kein Angriff gegen eine statische Huffman-Kodierung bekannt. Eine Studie hat gezeigt, dass die Verwendung einer statischen Huffman-Kodierungstabelle ein Informationsleck erzeugte; diese Studie kam jedoch zu dem Schluss, dass ein Angreifer dieses Informationsleck nicht ausnutzen könnte, um eine signifikante Menge an Informationen wiederherzustellen (siehe [PETAL]).

7.3. Speicherverbrauch (Memory Consumption)

Ein Angreifer kann versuchen, einen Endpunkt dazu zu bringen, seinen Speicher zu erschöpfen. HPACK ist so konzipiert, dass es sowohl die Spitzen- als auch die stabile Menge des von einem Endpunkt zugewiesenen Speichers begrenzt.

Die Menge des vom Komprimierungskontext verwendeten Speichers kann durch Festlegen einer maximalen Größe für die dynamische Tabelle begrenzt werden. In HTTP/2 wird dies durch den Parameter SETTINGS_HEADER_TABLE_SIZE gesteuert (siehe Abschnitt 6.5.2 von [HTTP2]).

Ein Encoder kann die Menge des Zustands, der bei einem Decoder erstellt werden kann, durch Steuerung der Größe der dynamischen Tabelle begrenzen. In HTTP/2 wird dies vom Decoder durch die Verwendung des Parameters SETTINGS_HEADER_TABLE_SIZE gemeldet. Ein Encoder MUSS die Größe der dynamischen Tabelle auf den vom Decoder gemeldeten Wert begrenzen und dadurch die Menge des zugewiesenen Speichers steuern.

Ein Decoder kann die Menge des für die dynamische Tabelle zugewiesenen Speichers begrenzen, indem er einen SETTINGS_HEADER_TABLE_SIZE-Wert signalisiert, der niedriger als der Standardwert ist. In HTTP/2 beträgt der Standardwert 4.096 Oktette, was bedeutet, dass der Encoder bis zu dieser Menge an Speicher für die dynamische Tabelle verwenden kann, es sei denn, der Decoder ändert dies, indem er einen SETTINGS_HEADER_TABLE_SIZE-Parameter in einem SETTINGS-Frame sendet.

7.4. Implementierungsgrenzen (Implementation Limits)

Eine Implementierung muss eine Grenze für die Werte festlegen, die sie für Ganzzahlen und für die Größe von Zeichenketten-Literalen akzeptiert. Ebenso muss sie eine Grenze für die Anzahl der Einträge festlegen, die sie in der dynamischen Tabelle speichern wird. Keine Grenze festzulegen könnte eine Implementierung Angriffen aussetzen, ähnlich wie es bei Protokollimplementierungen beobachtet wurde, die keine vernünftigen Grenzen festgelegt haben.

---