6. Sicherheitsüberlegungen

6.1. HTTP-Nachrichten sind nicht vollständig geschützt

Dieses Dokument spezifiziert einen Datenintegritätsmechanismus, der HTTP-Repräsentationsdaten oder -inhalte, jedoch nicht HTTP-Header- und Trailer-Felder, vor bestimmten Arten von Beschädigung schützt.

Integritätsfelder sind nicht als allgemeiner Schutz gegen böswillige Manipulation von HTTP-Nachrichten gedacht. Ohne zusätzliche Sicherheitsmechanismen kann ein böswilliger Akteur auf dem Pfad einen Digest-Wert entweder vollständig entfernen oder durch einen neuen Digest-Wert ersetzen, der über manipulierte Repräsentationsdaten oder Inhalte berechnet wurde. Dieser Angriff kann durch die Kombination der in diesem Dokument beschriebenen Mechanismen mit anderen Ansätzen wie Transport Layer Security (TLS) oder digitalen Signaturen (z. B. HTTP Message Signatures [SIGNATURES]) gemindert werden.

6.2. Ende-zu-Ende-Integrität

Integritätsfelder können helfen, Änderungen an Repräsentationsdaten oder Inhalten aufgrund von Implementierungsfehlern, unerwünschten "transformierenden Proxys" (siehe Abschnitt 7.7 von [HTTP]) oder anderen Aktionen zu erkennen, während die Daten mehrere Hops oder Systemgrenzen passieren. Selbst ein einfacher Mechanismus für die Ende-zu-Ende-Integrität von Repräsentationsdaten ist wertvoll, da ein User Agent überprüfen kann, ob der Ressourcenabruf erfolgreich war, bevor er ihn an einen HTML-Parser, Videoplayer usw. zur Analyse übergibt.

Beachten Sie, dass die alleinige Verwendung dieser Mechanismen keine Ende-zu-Ende-Integrität von HTTP-Nachrichten über mehrere Hops bietet, da Metadaten in jeder Phase manipuliert werden könnten. Methoden zum Schutz von Metadaten werden in Abschnitt 6.3 diskutiert.

6.3. Verwendung in Signaturen

Digitale Signaturen werden häufig zusammen mit Prüfsummen verwendet, um die sichere Identifizierung des Ursprungs einer Nachricht zu ermöglichen [FIPS186-5]. Solche Signaturen können ein oder mehrere HTTP-Felder schützen, und es gibt zusätzliche Überlegungen, wenn Integritätsfelder in diesem Satz enthalten sind.

Es gibt keine Einschränkungen hinsichtlich der Art oder des Formats der digitalen Signatur, mit der Integritätsfelder verwendet werden können. Ein möglicher Ansatz besteht darin, sie mit HTTP Message Signatures [SIGNATURES] zu kombinieren.

Digests hängen explizit von den "Repräsentationsmetadaten" ab (z. B. den Werten von Content-Type, Content-Encoding usw.). Eine Signatur, die Integritätsfelder, aber keine anderen "Repräsentationsmetadaten" schützt, kann die Kommunikation Manipulationen aussetzen. Ein Akteur könnte beispielsweise den Content-Type-Feldwert manipulieren und einen Fehler bei der Digest-Validierung beim Empfänger verursachen, wodurch die Anwendung am Zugriff auf die Repräsentation gehindert wird. Ein solcher Angriff verbraucht die Ressourcen beider Endpunkte. Siehe auch Abschnitt 3.2.

Signaturen werden bei der Anwendung von Integritätsfeldern wahrscheinlich als kontroverse Umgebung angesehen; siehe Abschnitt 5. Repr-Digest bietet in Kombination mit Signaturen eine interessante Möglichkeit. In dem Szenario, in dem kein Inhalt gesendet werden soll, kann der Digest einer leeren Zeichenfolge in die Nachricht aufgenommen werden und, wenn er signiert ist, dem Empfänger helfen, zu erkennen, ob Inhalt als Folge eines Unfalls oder einer absichtlichen Manipulation hinzugefügt wurde. Das umgekehrte Szenario wird ebenfalls unterstützt; das Einfügen eines Integritätsfelds für Inhalte und dessen Signierung kann einem Empfänger helfen, zu erkennen, wo der Inhalt entfernt wurde.

Jede Verstümmelung von Integritätsfeldern kann die Signaturvalidierung beeinträchtigen. Beispiele für eine solche Verstümmelung sind das Deduplizieren von Digests oder das Kombinieren verschiedener Feldwerte (siehe Abschnitt 5.2 von [HTTP]).

6.4. Verwendung in Trailer-Feldern

Vor dem Senden von Integritätsfeldern in einem Trailer-Abschnitt sollte der Absender berücksichtigen, dass Vermittler ausdrücklich berechtigt sind, jeden Trailer zu verwerfen (siehe Abschnitt 6.5.2 von [HTTP]).

Wenn Integritätsfelder in einem Trailer-Abschnitt verwendet werden, werden die Feldwerte nach dem Inhalt empfangen. Eine eifrige Verarbeitung von Inhalten vor dem Trailer-Abschnitt verhindert die Digest-Validierung, was möglicherweise zur Verarbeitung ungültiger Daten führt.

Einer der Vorteile der Verwendung von Integritätsfeldern in einem Trailer-Abschnitt besteht darin, dass Bytes gehasht werden können, während sie gesendet werden. Es ist jedoch möglich, einen Hashing-Algorithmus zu entwerfen, der eine Verarbeitung von Inhalten auf eine Weise erfordert, die diese Vorteile zunichtemachen würde. Beispielsweise erfordert Merkle Integrity Content Encoding [MICE], dass Inhalte in umgekehrter Reihenfolge verarbeitet werden. Dies bedeutet, dass die vollständigen Daten verfügbar sein müssen, was bedeutet, dass es einen vernachlässigbaren Verarbeitungsunterschied beim Senden eines Integritätsfelds in einem Header- gegenüber einem Trailer-Abschnitt gibt.

6.5. Variationen innerhalb von Content-Encoding

Content-Coding-Mechanismen können unterschiedliche Codierungsparameter unterstützen, was bedeutet, dass derselbe Eingabeinhalt unterschiedliche Ausgaben erzeugen kann. GZIP unterstützt beispielsweise mehrere Komprimierungsstufen. Solche Codierungsparameter werden im Allgemeinen nicht als Repräsentationsmetadaten kommuniziert. Beispielsweise würden verschiedene Komprimierungsstufen alle dasselbe Feld "Content-Encoding: gzip" verwenden. Andere Beispiele sind, wo die Codierung auf Nonces oder Zeitstempeln beruht, wie z. B. die in [RFC8188] definierte aes128gcm-Content-Codierung.

Da Variationen innerhalb der Content-Codierung möglich sind, kann die von den Integritätsfeldern übermittelte Prüfsumme nicht verwendet werden, um einen Integritätsnachweis "im Ruhezustand" zu erbringen, es sei denn, der gesamte Inhalt wird dauerhaft gespeichert.

6.6. Algorithmus-Agilität

Die Sicherheitseigenschaften von Hashing-Algorithmen sind nicht festgelegt. Algorithmus-Agilität (siehe [RFC7696]) wird erreicht, indem Implementierungen die Flexibilität erhalten, Hashing-Algorithmen aus dem IANA-Register für Hash-Algorithmen für HTTP-Digest-Felder auszuwählen; siehe Abschnitt 7.2.

Der Übergang von schwachen Algorithmen wird durch Aushandlung des Hashing-Algorithmus unter Verwendung von Want-Content-Digest oder Want-Repr-Digest (siehe Abschnitt 4) oder durch Senden mehrerer Digests, aus denen der Empfänger auswählt, unterstützt. Ein Empfänger, der aus Sicherheitsgründen von einem Digest abhängt, ist anfällig für Angriffe auf den schwächsten Algorithmus, den er zu akzeptieren bereit ist. Endpunkte werden darauf hingewiesen, dass das Senden mehrerer Werte Ressourcen verbraucht, die verschwendet werden können, wenn der Empfänger sie ignoriert (siehe Abschnitt 3).

Während Algorithmus-Agilität die Migration zu stärkeren Algorithmen ermöglicht, verhindert sie nicht die Verwendung schwächerer Algorithmen. Integritätsfelder bieten keine Abhilfemaßnahmen für Downgrade- oder Substitutionsangriffe (siehe Abschnitt 1 von [RFC6211]) des Hashing-Algorithmus. Um sich gegen solche Angriffe zu schützen, könnten Endpunkte ihren Satz unterstützter Algorithmen auf stärkere beschränken und die Werte der Felder durch Verwendung von TLS und/oder digitalen Signaturen schützen.

6.7. Ressourcenerschöpfung

Die Validierung von Integritätsfeldern verbraucht Rechenressourcen. Um eine Ressourcenerschöpfung zu vermeiden, können Implementierungen die Validierung der Algorithmustypen, die Anzahl der Validierungen oder die Größe des Inhalts einschränken. In diesen Fällen lässt das vollständige Überspringen der Validierung oder das Ignorieren eines Validierungsfehlers eines bevorzugteren Algorithmus die Möglichkeit eines Downgrade-Angriffs offen (siehe Abschnitt 6.6).