Zusammenfassung

  • Content-Digest prüft den tatsächlichen Nachrichteninhalt, Repr-Digest die vollständigen Daten der gewählten Repräsentation. Ein Treffer identifiziert nicht den Urheber der Bytes.
  • Eine belastbare Entscheidung trennt Bytebereich, Algorithmusregeln, Neuberechnung, Signaturabdeckung, Schlüsselbefugnis, Zeit, Replay, fachliche Prüfung und endgültige Aktion.

Die grüne Anzeige war nur teilweise wahr

Der neu berechnete Wert entsprach dem Feld. Genau diese eine Aussage war richtig. Unbegründet war die anschließende Folgerung, die Datei dürfe angewendet werden.

Wer Körper und Digest zugleich liefern kann, muss SHA-256 nicht angreifen. Er bildet den Hash seines eigenen schädlichen Inhalts. Der Empfänger wiederholt die Rechnung und erhält erwartungsgemäß dasselbe Ergebnis. Bewiesen ist die Übereinstimmung zweier Eingaben, nicht die Vertrauenswürdigkeit ihrer Quelle.

Darum ist verified=true kein entscheidungstauglicher Befund. Benötigt werden Bezeichnungen wie content_digest_matched, signature_verified, key_authorized und replay_rejected. Das benannte Objekt begrenzt die Reichweite des Nachweises.

Zuerst den Bytebereich bestimmen

RFC 9530 definiert Content-Digest für den tatsächlichen Inhalt einer HTTP-Nachricht und Repr-Digest für die gesamten Daten der ausgewählten Repräsentation. Inhaltscodierung, Bereichsantworten, Methoden und Repräsentationsmetadaten können beide Bereiche auseinanderfallen lassen.

Ein Gateway kann komprimierte Bytes prüfen, während die Anwendung glaubt, die decodierte Repräsentation sei geprüft worden. Beide Meldungen können lokal stimmen und dennoch unterschiedliche Objekte betreffen. Vor der Wahl von SHA-256 oder SHA-512 steht daher die Frage: Welche Bytes müssen an welcher Transformationsgrenze unverändert bleiben?

Die Ablösung von RFC 3230 zeigt, warum das wichtig ist. Dessen Begriff „instance“ wurde uneinheitlich verstanden, besonders als Verwechslung von Nachrichteninhalt und Repräsentationsdaten. Präzisere Namen helfen nur, wenn Protokolle und Tests sie bewahren.

Ein korrektes Wörterbuch ist kein Ausweis

Beide Felder sind Structured-Fields-Wörterbücher. Der Schlüssel benennt den Algorithmus, der Wert transportiert die Digest-Bytesequenz. Mehrere Algorithmen können einen Übergang unterstützen.

Erfolgreiches Parsen ist noch keine Annahmeentscheidung. Der Empfänger braucht eine Positivliste, Regeln für mehrere Werte und ein eindeutiges Fehlerverhalten. Das IANA-Register führt Statusangaben. RFC 9530 empfiehlt für viele Zwecke aktive Algorithmen und verbietet veraltete Algorithmen in potenziell gegnerischen Situationen.

Base64 codiert lediglich Bytes. Codierung, Hashbildung und Signatur sind getrennte Vorgänge. Auch Want-Content-Digest und Want-Repr-Digest sind nur Präferenzhinweise und dürfen ignoriert werden. Eine Pflicht muss die Anwendung selbst definieren.

Die Signatur ersetzt die Neuberechnung nicht

HTTP Message Signatures können Content-Digest, Methode, Ziel und weitere ausgewählte Komponenten abdecken. Wird das Feld eingeschlossen, lässt sich sein deklarierter Wert an einen verifizierten Schlüssel binden.

Eine Signatur deckt jedoch nicht stillschweigend die gesamte Nachricht ab. Fehlt Content-Digest in der Signaturbasis, folgt aus einer gültigen Signatur nichts über dieses Feld. Ist es enthalten, muss der Empfänger den Digest des tatsächlich empfangenen Körpers weiterhin selbst berechnen.

Wird der Körper durch einen Fehler ersetzt, das signierte Digest-Feld aber beibehalten, kann die Signatur gültig bleiben. Erst die unabhängige Neuberechnung entdeckt die Abweichung. Umgekehrt lässt eine Digest-Prüfung ohne Signatur jeden Unbekannten einen neuen Körper samt passendem Wert liefern.

Auch eine echte Signatur ist noch keine Berechtigung. Die Anwendung muss Schlüsselbefugnis, erforderliche Komponenten, Algorithmus, Erstellungs- und Ablaufzeit sowie Nonce- oder andere Replay-Regeln prüfen.

Trailer verschieben den Entscheidungszeitpunkt

RFC 9530 erlaubt Integritätsfelder im Header oder Trailer. Bei einem Datenstrom kann der Absender den Wert erst am Ende kennen. Dann erhält auch der Empfänger seinen vollständigen Nachweis erst am Ende.

Schreibt die Anwendung während des Lesens bereits dauerhaften Zustand und prüft danach den Trailer, kommt ein Fehler zu spät. Daten müssen vorbereitet oder in einer rückrollbaren Transaktion gehalten werden, bis alle Prüfungen beendet sind.

HTTP/1.1, HTTP/2 und HTTP/3 transportieren Trailer unterschiedlich. Proxys und Frameworks können sie verwerfen oder anders verfügbar machen. Nur ein Lauf durch den echten Produktionspfad beweist, dass die entscheidende Komponente das Feld vor dem Commit erhält.

Unveränderte Bytes können trotzdem veraltet sein

Ein Cacheobjekt kann dieselben Bytes und einen passenden Digest behalten, obwohl es nicht mehr frisch ist. RFC 9111 regelt Frische, Revalidierung und die Nutzung veralteter Antworten unabhängig davon.

Ebenso kann eine vollständig gültige signierte Anfrage erneut gesendet werden. Körper, Digest und Signatur bestehen die Prüfung wieder. Zeitfenster, Nonce, Anfragekennung und Idempotenzregeln entscheiden über die zweite Ausführung.

Die Semantik bleibt ebenfalls eigenständig. Eine formal gültige Konfiguration kann gefährliche Rechte vergeben. Ein Paket kann zum veröffentlichten Digest passen und verwundbaren Code enthalten. Integrität erhält das vorgelegte Objekt, genehmigt aber nicht seine Wirkung.

Der Negativtest legt die Grenze offen

Zuerst wird schädlicher Inhalt mit seinem korrekten Digest eingereicht. Die Integritätsprüfung muss bestehen, die Autorisierung muss die Aktion ablehnen. Danach wird ein Byte geändert und der Digest beibehalten; der Fehler muss vor jeder Zustandsänderung auftreten.

Dann wird eine Anfrage signiert, die Content-Digest nicht abdeckt. Im nächsten Fall wird das Feld abgedeckt, aber der Körper geändert. Mehrere, unbekannte und veraltete Algorithmen prüfen, ob Reihenfolge zu einer Herabstufung führt. Komprimierung, Bereiche und Rekonstruktion zeigen den gewählten Bytebereich.

Schließlich müssen Trailer jede unterstützte HTTP-Version und jeden Vermittler durchlaufen. Eine gültige Anfrage wird wiederholt, ein veraltetes Cacheobjekt mit passendem Digest ausgeliefert. Jede Schranke soll nur ihre eigene Frage beantworten.