4. Security Considerations (Sicherheitsüberlegungen)
4. Security Considerations (Sicherheitsüberlegungen)
Die hier beschriebenen Header-Felder ermöglichen es einem TTRP und einem Backend- oder Ursprungsserver, zusammen zu funktionieren, als wären sie aus Sicht des Clients ein einzelnes logisches serverseitiges Deployment von HTTPS über eine gegenseitig authentifizierte TLS-Verbindung. Die Verwendung der Header-Felder außerhalb dieses beabsichtigten Anwendungsfalls kann jedoch die durch TLS-Client-Zertifikatauthentifizierung gebotenen Schutzmaßnahmen untergraben. Daher müssen Schritte wie die unten beschriebenen unternommen werden, um eine unbeabsichtigte Verwendung zu verhindern, sowohl beim Senden des Header-Feldes als auch beim Verlassen auf seinen Wert.
Das Erzeugen und Konsumieren der Client-Cert- und Client-Cert-Chain-Header-Felder SOLLTE jeweils in einem TTRP und Backend-Server (oder in einer einzelnen Anwendung auf diesem Server) konfigurierbare Optionen sein. Die Standardkonfiguration für beide sollte sein, die Header-Felder nicht zu verwenden, was ein "Opt-in" zur Funktionalität erfordert.
Um Feldinjektionen (field injection) zu verhindern, MÜSSEN Backend-Server die Client-Cert- und Client-Cert-Chain-Header-Felder nur von einem vertrauenswürdigen TTRP (oder einem anderen Proxy in einem vertrauenswürdigen Pfad vom TTRP) akzeptieren. Ein TTRP MUSS die eingehende Anfrage vor dem Weiterleiten bereinigen, indem er alle vorhandenen Instanzen der Felder entfernt oder überschreibt. Andernfalls können beliebige Clients die Feldwerte kontrollieren, wie sie vom Backend-Server gesehen und verwendet werden. Es ist wichtig zu beachten, dass das Versäumnis, Feldinjektionen zu verhindern, nicht "fail safe" ist, da die nominale Funktionalität auch dann wie erwartet funktionieren wird, wenn bösartige Aktionen möglich sind. Daher wird besondere Sorgfalt empfohlen, um sicherzustellen, dass eine ordnungsgemäße Feldbereinigung vorhanden ist.
Die Kommunikation zwischen einem TTRP und einem Backend-Server muss gegen Abhören und Änderungen durch unbeabsichtigte Parteien gesichert werden.
Die Konfigurationsoptionen und die Anforderungsbereinigung sind notwendige Funktionalitäten der jeweiligen Server. Die anderen Anforderungen können auf verschiedene Weise erfüllt werden, die je nach spezifischen Bereitstellungen variieren. Die Kommunikation zwischen einem TTRP und einem Backend- oder Ursprungsserver könnte beispielsweise auf irgendeine Weise authentifiziert werden, wobei das Einfügen und Konsumieren der Client-Cert- und Client-Cert-Chain-Header-Felder nur auf dieser Verbindung erfolgt. Anhang B.3 von [HTTPSIG] gibt ein Beispiel hierfür mit einer Anwendung von HTTP-Nachrichtensignaturen (HTTP Message Signatures). Alternativ könnte die Netzwerktopologie ein privates Netzwerk vorschreiben, so dass die Backend-Anwendung nur Anfragen vom TTRP akzeptieren kann und der Proxy nur Anfragen an diesen Server stellen kann. Andere Bereitstellungen, die die hier dargelegten Anforderungen erfüllen, sind ebenfalls möglich.