9. Sicherheitsüberlegungen
9.1. Wechseln von Ports
Die Verwendung eines alternativen Dienstes impliziert den Zugriff auf die Ressourcen eines Ursprungs zumindest auf einem alternativen Port. Daher ist ein Angreifer, der in der Lage ist, alternative Dienste einzuschleusen und auf dem beworbenen Port zu lauschen, in der Lage, einen Ursprung zu kapern. Auf einigen Servern ist es normal, dass Benutzer einige persönliche Seiten kontrollieren können, die auf einem gemeinsamen Port verfügbar sind, und auch Anforderungen auf weniger privilegierten Ports annehmen können.
Zum Beispiel kann ein Angreifer, der einigen Seiten HTTP-Antwort-Header-Felder hinzufügen kann, den Datenverkehr für einen gesamten Ursprung mithilfe des Alt-Svc Header-Feldes auf einen anderen Port auf demselben Host umleiten; wenn dieser Port unter der Kontrolle des Angreifers steht, kann er sich als der HTTP-Server ausgeben.
Dieses Risiko wird durch die Anforderungen in Abschnitt 2.1 gemindert.
Auf Servern kann dieses Risiko auch verringert werden, indem die Fähigkeit, alternative Dienste zu bewerben, eingeschränkt wird und indem eingeschränkt wird, wer auf diesem Host einen Port zum Lauschen öffnen kann.
9.2. Wechseln von Hosts
Wenn der Host aufgrund der Verwendung eines alternativen Dienstes geändert wird, bietet dies Angreifern die Möglichkeit, die Kommunikation zu einem Ursprung zu kapern.
Wenn ein Angreifer beispielsweise einen User Agent davon überzeugen kann, den gesamten Datenverkehr für "innocent.example.org" an "evil.example.com" zu senden, indem er ihn erfolgreich als alternativen Dienst zuordnet, kann er sich als dieser Ursprung ausgeben. Dies kann lokal (siehe die Abhilfemaßnahmen in Abschnitt 9.1) oder entfernt (z. B. durch einen Vermittler als Man-in-the-Middle-Angriff) erfolgen.
Dies ist der Grund für die Anforderung in Abschnitt 2.1, dass Clients hinreichende Sicherheiten haben müssen, dass der alternative Dienst unter der Kontrolle des gesamten Ursprungs steht und für diesen gültig ist; zum Beispiel beweist die Vorlage eines Zertifikats für den Ursprung, dass der alternative Dienst autorisiert ist, den Verkehr für den Ursprung zu bedienen.
Beachten Sie, dass diese Sicherheit nur so stark ist wie die Methode, die zur Authentifizierung des alternativen Dienstes verwendet wird. Insbesondere wenn dazu TLS-Authentifizierung verwendet wird, gibt es bekannte Exploits, um das Zertifikat eines Angreifers legitim erscheinen zu lassen.
Alternative Dienste könnten verwendet werden, um einen solchen Angriff dauerhaft zu machen. Beispielsweise könnte ein Vermittler die TLS-geschützte Kommunikation zu einem Ziel abfangen (Man-in-the-Middle) und dann den gesamten Datenverkehr auf einen alternativen Dienst mit einer langen Frische-Lebensdauer leiten, sodass der User Agent den Datenverkehr auch dann weiterhin an den Angreifer leitet, wenn der Vermittler nicht verwendet wird.
Implementierungen MÜSSEN jede Zertifikats-Pinning-Validierung (wie [RFC7469]) für alternative Dienste genauso durchführen, wie sie es für direkte Verbindungen zum Ursprung tun würden. Implementierungen können auch zusätzliche Anforderungen daran stellen, welche Zertifikate für alternative Dienste akzeptabel sind.
9.3. Wechseln von Protokollen
Wenn das ALPN-Protokoll aufgrund der Verwendung eines alternativen Dienstes geändert wird, können sich die Sicherheitseigenschaften der neuen Verbindung zum Ursprung von denen der "normalen" Verbindung zum Ursprung unterscheiden, da der Protokollbezeichner selbst dies impliziert.
Wenn beispielsweise ein "https://" URI ein Protokoll bewirbt, das keine Form von Ende-zu-Ende-Verschlüsselung (höchstwahrscheinlich TLS) verwendet, verstößt dies gegen die Sicherheitserwartungen, die das URI-Schema impliziert. Daher können Clients alternative Dienste nicht blindlings verwenden, sondern müssen die angebotene(n) Option(en) bewerten, um sicherzustellen, dass Sicherheitsanforderungen und Erwartungen von Spezifikationen, Implementierungen und Endbenutzern erfüllt werden.
9.4. Tracking von Clients durch alternative Dienste
Die Wahl eines alternativen Dienstes impliziert das Verbinden mit einem neuen, vom Server bereitgestellten Hostnamen. Durch die Verwendung eindeutiger Namen könnten Server Client-Anforderungen denkbar verfolgen. Ein solches Tracking könnte Benutzer über mehrere Netzwerke hinweg verfolgen, wenn das "persist"-Flag verwendet wird.
Clients, die verhindern möchten, dass Anforderungen korreliert werden, können entscheiden, keine alternativen Dienste für mehrere Anforderungen zu verwenden, die sonst nicht korreliert werden dürften.
In einem User Agent MÜSSEN alle Informationen über alternative Dienste entfernt werden, wenn ursprungsspezifische Daten gelöscht werden (in der Regel, wenn Cookies [RFC6265] gelöscht werden).
9.5. Verwirrung bezüglich des Anforderungsschemas
Einige serverseitige HTTP-Anwendungen treffen Annahmen über die Sicherheit basierend auf dem Verbindungskontext; z. B. Gleichsetzung der Bereitstellung auf Port 443 mit der Verwendung eines "https://" URI und den verschiedenen Sicherheitseigenschaften, die dies impliziert.
Dies betrifft nicht nur die Sicherheitseigenschaften der Verbindung selbst, sondern auch den Zustand des Clients am anderen Ende; zum Beispiel behandelt ein Webbrowser "https://" URIs in vielerlei Hinsicht anders als "http://" URIs, nicht nur für Zwecke der Protokollbehandlung.
Da eine der Verwendungen alternativer Dienste darin besteht, die Migration einer Verbindung zu einem anderen Protokoll und Port zu ermöglichen, können diese Anwendungen bezüglich der Sicherheitseigenschaften einer bestimmten Verbindung verwirrt werden und Informationen (z. B. Cookies und Inhalte), die für einen sicheren Kontext (wie einen "https://" URI) bestimmt sind, an einen Client senden, der ihn nicht als solchen behandelt.
Dieses Risiko kann in Servern gemindert werden, indem das vom Protokoll explizit übertragene URI-Schema (wie ":scheme" in HTTP/2 oder die "absolute Form" des Anforderungsziels in HTTP/1.1) als Hinweis auf den Sicherheitskontext verwendet wird, anstatt anderer Verbindungseigenschaften ([RFC7540], Abschnitt 8.1.2.3 und [RFC7230], Abschnitt 5.3.2).
Wenn das Protokoll das Schema nicht explizit überträgt (wie es bei HTTP/1.1 über TLS normalerweise der Fall ist), können Server dieses Risiko mindern, indem sie entweder davon ausgehen, dass alle Anforderungen einen unsicheren Kontext haben, oder indem sie darauf verzichten, alternative Dienste für unsichere Schemata (z. B. HTTP) zu bewerben.