2. Konzepte alternativer Dienste
Diese Spezifikation definiert ein neues Konzept in HTTP, den "Alternativen Dienst" (Alternative Service). Wenn ein Ursprung [RFC6454] Ressourcen hat, die über eine andere Protokoll/Host/Port-Kombination zugänglich sind, wird gesagt, dass er einen alternativen Dienst zur Verfügung hat.
Ein alternativer Dienst kann verwendet werden, um mit den Ressourcen auf einem Ursprungsserver an einem separaten Ort im Netzwerk zu interagieren, möglicherweise unter Verwendung einer anderen Protokollkonfiguration. Alternative Dienste gelten im Sinne von [RFC7230], Abschnitt 9.1, als autoritativ für die Ressourcen eines Ursprungs.
Zum Beispiel könnte ein Ursprung:
("http", "www.example.com", "80")
erklären, dass seine Ressourcen auch unter dem alternativen Dienst zugänglich sind:
("h2", "new.example.com", "81")
Naturgegeben sind alternative Dienste explizit auf der Granularität eines Ursprungs; sie können nicht selektiv auf Ressourcen innerhalb eines Ursprungs angewendet werden.
Alternative Dienste ersetzen oder ändern den Ursprung für eine bestimmte Ressource nicht; im Allgemeinen sind sie für die Software "oberhalb" des Zugriffsmechanismus nicht sichtbar. Der alternative Dienst ist im Wesentlichen eine alternative Routing-Information, die auch verwendet werden kann, um den Ursprung auf die gleiche Weise zu erreichen, wie DNS-CNAME- oder SRV-Einträge Routing-Informationen auf der Ebene der Namensauflösung definieren. Jeder Ursprung wird auf eine Menge dieser Routen abgebildet -- die Standardroute wird vom Ursprung selbst abgeleitet und die anderen Routen werden basierend auf Informationen über alternative Dienste eingeführt.
Darüber hinaus ist es wichtig zu beachten, dass das erste Element eines Tupels eines alternativen Dienstes sich von der "Schema"-Komponente eines Ursprungs unterscheidet; es ist spezifischer und identifiziert nicht nur die Hauptversion des verwendeten Protokolls, sondern möglicherweise auch die Kommunikationsoptionen für dieses Protokoll.
Das bedeutet, dass Clients, die einen alternativen Dienst verwenden, den Host, den Port und das Protokoll ändern können, die sie zum Abrufen von Ressourcen verwenden, aber diese Änderungen DÜRFEN NICHT an die Anwendung weitergegeben werden, die HTTP verwendet; von diesem Standpunkt aus sind der aufgerufene URI und alle daraus abgeleiteten Informationen (Schema, Host und Port) dieselben wie zuvor.
Wichtig ist, dass dies seinen Sicherheitskontext einschließt; insbesondere wenn TLS [RFC5246] zur Authentifizierung verwendet wird, muss der alternative Dienst ein Zertifikat für den Hostnamen des Ursprungs vorlegen, nicht das des alternativen Dienstes. Ebenso wird das Host-Header-Feld ([RFC7230], Abschnitt 5.4) immer noch vom Ursprung abgeleitet, nicht vom alternativen Dienst (genau wie es der Fall wäre, wenn ein CNAME verwendet würde).
Die Änderungen KÖNNEN jedoch in Debugging-Tools, Konsolen usw. sichtbar gemacht werden.
Formal wird ein alternativer Dienst durch die Kombination von Folgendem identifiziert:
- Einem ALPN-Protokollnamen (Application Layer Protocol Negotiation) gemäß [RFC7301]
- Einem Host gemäß [RFC3986], Abschnitt 3.2.2
- Einem Port gemäß [RFC3986], Abschnitt 3.2.3
Der ALPN-Protokollname wird verwendet, um das Anwendungsprotokoll oder die Protokollsuite zu identifizieren, die vom alternativen Dienst verwendet wird. Beachten Sie, dass für die Zwecke dieser Spezifikation ein ALPN-Protokollname implizit TLS in der Protokollsuite enthält, die er identifiziert, sofern in seiner Definition nichts anderes angegeben ist. Insbesondere identifiziert der ALPN-Name "http/1.1", der durch Abschnitt 6 von [RFC7301] registriert wurde, HTTP/1.1 über TLS.
Zusätzlich muss jeder alternative Dienst eine Frische-Lebensdauer haben, die in Sekunden ausgedrückt wird (siehe Abschnitt 2.2).
Es gibt viele Möglichkeiten, wie ein Client den/die einem Ursprung zugeordneten alternativen Dienst(e) entdecken könnte. Dieses Dokument beschreibt zwei solcher Mechanismen: das "Alt-Svc" HTTP Header-Feld (Abschnitt 3) und den "ALTSVC" HTTP/2 Frame-Typ (Abschnitt 4).
Der Rest dieses Abschnitts beschreibt Anforderungen, die für alternative Dienste gelten, unabhängig davon, wie sie entdeckt werden.
2.1. Host-Authentifizierung
Clients MÜSSEN hinreichende Sicherheit haben, dass der alternative Dienst unter der Kontrolle des gesamten Ursprungs steht und für diesen gültig ist. Dies mindert den in Abschnitt 9.2 beschriebenen Angriff.
Für die Zwecke dieses Dokuments können "hinreichende Sicherheiten" durch die Verwendung eines TLS-basierten Protokolls mit den in [RFC2818] definierten Zertifikatsüberprüfungen hergestellt werden. Clients KÖNNEN zusätzliche Kriterien zur Herstellung hinreichender Sicherheiten auferlegen.
Wenn beispielsweise der Host des Ursprungs "www.example.com" ist und eine Alternative auf "other.example.com" mit dem "h2"-Protokoll angeboten wird und das angebotene Zertifikat für "www.example.com" gültig ist, kann der Client die Alternative verwenden. Wenn jedoch eine der beiden mit dem "h2c"-Protokoll angeboten wird, kann der Client sie nicht verwenden, da es (zum Zeitpunkt der Veröffentlichung dieser Spezifikation) in diesem Protokoll keinen Mechanismus gibt, um die Beziehung zwischen dem Ursprung und der Alternative herzustellen.
2.2. Caching alternativer Dienste
Mechanismen zum Entdecken alternativer Dienste ordnen diesen auch eine Frische-Lebensdauer zu; beispielsweise verwendet das Alt-Svc Header-Feld den Parameter "ma".
Clients können jederzeit entscheiden, einen alternativen Dienst anstelle des Ursprungs zu verwenden, wenn dieser als frisch gilt; siehe Abschnitt 2.4 für spezifische Empfehlungen.
Clients mit bestehenden Verbindungen zu einem alternativen Dienst müssen die Verwendung nicht beenden, wenn seine Frische-Lebensdauer endet; der Caching-Mechanismus soll begrenzen, wie lange ein alternativer Dienst für den Aufbau neuer Verbindungen verwendet werden kann, nicht die Verwendung bestehender Verbindungen einschränken.
Alternative Dienste sind für den betreffenden Ursprung vollständig autoritativ, einschließlich der Möglichkeit, zwischengespeicherte Einträge für alternative Dienste zu löschen oder zu aktualisieren, Frische-Lebensdauern zu verlängern und jede andere Autorität, die der Ursprungsserver hätte.
Wenn alternative Dienste verwendet werden, um einen Client zum optimalsten Server zu senden, kann eine Änderung der Netzwerkkonfiguration dazu führen, dass zwischengespeicherte Werte suboptimal werden. Daher SOLLTEN Clients alle alternativen Dienste aus dem Cache entfernen, denen das "persist"-Flag mit dem Wert "1" fehlt, wenn sie eine solche Änderung erkennen, wenn Informationen über den Netzwerkstatus verfügbar sind.
2.3. Erfordernis der Server Name Indication
Ein Client DARF KEINEN TLS-basierten alternativen Dienst verwenden, es sei denn, der Client unterstützt TLS Server Name Indication (SNI). Dies unterstützt die Einsparung von IP-Adressen auf dem Host des alternativen Dienstes.
Beachten Sie, dass die vom Client in TLS bereitgestellten SNI-Informationen die des Ursprungs sind, nicht die der Alternative (ebenso wie der Wert des Host HTTP Header-Feldes).
2.4. Verwendung alternativer Dienste
Naturgegeben sind alternative Dienste OPTIONAL: Clients müssen sie nicht verwenden. Es ist jedoch vorteilhaft, wenn Clients sich auf vorhersehbare Weise verhalten, wenn alternative Dienste von Servern verwendet werden, um Zwecke wie Lastausgleich zu unterstützen.
Wenn ein Client, der diese Spezifikation unterstützt, von einem alternativen Dienst erfährt, SOLLTE der Client diesen alternativen Dienst daher für alle Anforderungen an den zugehörigen Ursprung verwenden, sobald er verfügbar ist, vorausgesetzt, die Informationen zum alternativen Dienst sind frisch (Abschnitt 2.2) und die Sicherheitseigenschaften des Protokolls des alternativen Dienstes sind im Vergleich zur bestehenden Verbindung wünschenswert. Ein praktikabler alternativer Dienst wird dann in jeder Hinsicht als Ursprung behandelt; dies schließt die Fähigkeit ein, alternative Dienste zu bewerben.
Wenn ein Client von mehreren alternativen Diensten erfährt, wählt er den geeignetsten nach seinen eigenen Kriterien aus, wobei er die Sicherheitseigenschaften im Auge behält. Beispielsweise könnte ein Ursprung mehrere alternative Dienste bewerben, um Clients über die Unterstützung für mehrere Versionen von HTTP zu informieren.
Ein Client, der so konfiguriert ist, dass er für eine bestimmte Anforderung einen Proxy verwendet, SOLLTE SICH NICHT direkt mit einem alternativen Dienst für diese Anforderung verbinden, sondern sie stattdessen über diesen Proxy leiten.
Wenn ein Client einen alternativen Dienst für eine Anforderung verwendet, kann er dies dem Server mithilfe des Alt-Used Header-Feldes mitteilen (Abschnitt 5).
Der Client muss Anforderungen auf keiner bestehenden Verbindung blockieren; sie kann verwendet werden, bis die alternative Verbindung hergestellt ist. Wenn jedoch die Sicherheitseigenschaften der bestehenden Verbindung schwach sind (z. B. Klartext-HTTP/1.1), kann es sinnvoll sein, zu blockieren, bis die neue Verbindung vollständig verfügbar ist, um Informationslecks zu vermeiden.
Wenn die Verbindung zum alternativen Dienst fehlschlägt oder nicht reagiert, KANN der Client außerdem auf die Verwendung des Ursprungs oder eines anderen alternativen Dienstes zurückgreifen. Beachten Sie jedoch, dass dies die Grundlage für einen Downgrade-Angriff sein könnte, wodurch alle verbesserten Sicherheitseigenschaften des alternativen Dienstes verloren gehen. Wenn die Verbindung zum alternativen Dienst nicht das erwartete Protokoll aushandelt (z. B. ALPN verhandelt h2 nicht oder eine Upgrade-Anforderung auf h2c wird nicht akzeptiert), MUSS die Verbindung zum alternativen Dienst als fehlgeschlagen betrachtet werden.