Zusammenfassung

  • Ein ORIGIN-Frame nennt Ursprünge, die ein unterstützender HTTP/2-Client einer Verbindung zuordnen kann.
  • Die Mitgliedschaft im Origin Set bleibt von einem gültigen Zertifikat für den Ursprung abhängig; der Frame erzeugt keine Zuständigkeit für einen Ursprung.
  • Gültigkeit ist verbindungs- und hopbezogen; fehlerhafte Einträge sowie Frames vom Proxy, falschen Stream oder Protokoll werden ignoriert.
  • Ein Nachweis der Verbindungswiederverwendung verbindet gültigen Frame, exakten Ursprung, Zertifikatsentscheidung, Clientwahl, Anfrageergebnis und eine mögliche Entfernung nach 421.

Man stelle sich einen gemeinsamen Edge vor, der in einem ORIGIN-Frame einen zweiten HTTPS-Dienst nennt. Das Dashboard sieht den Namen im Mitschnitt und streicht dessen eigenen Verbindungstest. Im Zertifikat der gemeinsamen Verbindung fehlt der Name. Dieser Client verwendet die Verbindung daher nicht erneut und öffnet eine andere. In einem getrennten Test mit veraltetem Zustand sendet eine andere Clientinstanz die Anfrage über die frühere Verbindung und erhält 421 Misdirected Request. Der Frame war echt, die Autoritätsaussage nicht.

Dies ist eine hypothetische Spur, kein berichteter Vorfall. Der Fehler liegt darin, Serverbehauptung, Cliententscheidung und Anfrageergebnis zu einer Kennzahl zu machen.

Der Frame verändert eine Verbindungsmenge

RFC 8336 definiert ORIGIN als HTTP/2-Erweiterung zur Initialisierung oder Änderung des Origin Set eines unterstützenden Clients. Jeder Eintrag serialisiert genau einen Ursprung. Er ist weder Platzhalter noch Weiterleitung oder neue Ressourcenidentität.

Der Frame darf nur auf Stream 0 gesendet werden und ist auf h2 oder einem ausdrücklich teilnehmenden Protokoll gültig; auf h2c wird er ignoriert. Die Erweiterung ist nicht kritisch. Sie gilt nur für den jeweiligen Übertragungsabschnitt: Vermittler dürfen sie nicht weiterleiten, und Clients mit Proxy ignorieren von ihm erhaltene Frames. Ohne Verbindung, Protokoll, Stream und Absender beweist ein Mitschnitt keine Verarbeitung.

Unlesbare Einträge werden ignoriert. ORIGIN unterstützt keine Wildcard-Namen; jeder Ursprung wird ausdrücklich aufgeführt. Wildcard-Zertifikat und Origin Set sind daher verschiedene Listen.

Mitgliedschaft ist keine Autorität

Nach der Initialisierung begrenzt das Set die Verbindungswiederverwendung: Für einen fehlenden Ursprung darf der Client die Verbindung nicht für diesen Ursprung verwenden. Anwesenheit genügt ebenfalls nicht. RFC 8336 verlangt weiterhin ein Zertifikat mit geeigneten Prüfungen, einschließlich der Übereinstimmung mit subjectAltName.

RFC 9110 bindet HTTPS-Autorität an eine erfolgreich gesicherte Verbindung und ein für den Ursprung vertrauenswürdiges Zertifikat. Ein ORIGIN-Eintrag schafft kein Vertrauen, erweitert keine Namen und hebt keine Clientrichtlinie auf.

R065 wiederholt R064 nicht. Alt-Svc nominiert einen anderen Dienstpfad; ORIGIN beschreibt Ursprünge einer Verbindung. Laut RFC 8336 verändert eine Alt-Svc-Ankündigung weder Origin Set noch Autorität.

Autorität kann sich verändern

Spätere gültige Frames können Einträge hinzufügen. Nach 421 Misdirected Request entfernt der unterstützende Client den betreffenden Ursprung. Die frühere Angabe gilt daher nicht dauerhaft.

Clients dürfen unter Umständen DNS überspringen, doch RFC 8336 nennt zusätzliche Risiken und fordert auf anderem Weg hohe Sicherheit über die Legitimität des Zertifikats. Das ist eine Richtlinie, kein Beweis einheitlichen Verhaltens.

Validieren Sie die Änderung mit einem Prüfprotokoll für die Verbindungswiederverwendung: Verbindung, Protokoll, Stream, Rohdaten des Frames, Absender, Parsergebnis und Reihenfolge des Sets. Je Ursprung gehören Zertifikatskette, Vertrauen, exakter SAN-Treffer, DNS-Nachweis, Wiederverwendungsentscheidung, Anfrageergebnis und 421-Entfernung dazu. Begrenzen Sie die Aussage auf beobachtete Clients und Zeit.

Quellen