1. Introduction (Einführung)
1. Introduction (Einführung)
Ein ziemlich übliches Bereitstellungsmuster für HTTPS-Anwendungen besteht darin, die ursprünglichen HTTP-Anwendungsserver hinter einem Reverse-Proxy zu platzieren, der TLS-Verbindungen von Clients terminiert. Der Proxy ist über das Internet zugänglich und leitet Client-Anfragen an den entsprechenden Ursprungsserver innerhalb eines privaten oder geschützten Netzwerks weiter. Die Ursprungsserver sind nicht direkt von Clients aus zugänglich und nur über den Reverse-Proxy erreichbar. Die Backend-Details dieser Art von Bereitstellung sind für Clients, die Anfragen an den Proxy-Server stellen, typischerweise undurchsichtig, und sie sehen Antworten, als ob sie vom Proxy-Server selbst stammen würden. Obwohl HTTPS normalerweise auch zwischen dem Proxy und dem Ursprungsserver verwendet wird, besteht die TLS-Verbindung, die der Client für HTTPS herstellt, nur zwischen sich selbst und dem Reverse-Proxy-Server.
Das Bereitstellungsmuster findet sich in einer Reihe von Varianten wie n-Schicht-Architekturen (n-tier architectures), Content-Delivery-Netzwerken (content delivery networks), Anwendungslastausgleichsdiensten (application load-balancing services) und Ingress-Controllern (ingress controllers).
Obwohl nicht übermäßig verbreitet, wird manchmal TLS-Client-Zertifikatauthentifizierung (TLS client certificate authentication) eingesetzt, und in solchen Fällen benötigt der Ursprungsserver häufig Informationen über das Client-Zertifikat für seine Anwendungslogik. Eine solche Logik kann Zugriffssteuerungsentscheidungen, Audit-Protokollierung und Bindung ausgestellter Token (tokens) oder Cookies an ein Zertifikat umfassen, einschließlich der jeweiligen Validierung solcher Bindungen. Die spezifischen Details, die vom Zertifikat benötigt werden, variieren auch je nach Anwendungsanforderungen. Damit diese Arten von Anwendungsbereitstellungen in der Praxis funktionieren, muss der Reverse-Proxy Informationen über das Client-Zertifikat an den ursprünglichen Anwendungsserver übermitteln. Zum Zeitpunkt des Schreibens ist eine gängige Art, diese Informationen zu übermitteln, die Verwendung nicht standardmäßiger Felder (non-standard fields), um das Zertifikat (in irgendeiner Kodierung) oder einzelne Teile davon in der HTTP-Anfrage zu transportieren, die an den Ursprungsserver weitergeleitet wird. Diese Lösung funktioniert, aber die Interoperabilität zwischen unabhängig entwickelten Komponenten kann umständlich oder sogar unmöglich sein, abhängig von den jeweils getroffenen Implementierungsentscheidungen (wie welche Feldnamen verwendet oder konfigurierbar sind, welche Teile des Zertifikats offengelegt werden oder wie das Zertifikat kodiert wird). Ein bekannter vorhersehbarer Ansatz für diese häufig vorkommende Funktionalität könnte die Interoperabilität zwischen unabhängigen Implementierungen verbessern und vereinfachen.
Der Umfang dieses Dokuments besteht darin, bestehende Praktiken zu beschreiben und gleichzeitig spezifische Details zu kodifizieren, die ausreichen, um eine verbesserte und berührungsärmere Interoperabilität zu ermöglichen. Als solches beschreibt dieses Dokument zwei HTTP-Header-Felder, "Client-Cert" und "Client-Cert-Chain", die ein TLS-terminierender Reverse-Proxy (TLS Terminating Reverse Proxy, TTRP) zu Anfragen hinzufügt, die an die Backend-Ursprungsserver gesendet werden. Der Client-Cert-Feldwert enthält das Endentitäts-Client-Zertifikat (end-entity client certificate) aus der gegenseitig authentifizierten TLS-Verbindung zwischen dem ursprünglichen Client und dem TTRP. Optional enthält der Client-Cert-Chain-Feldwert die Zertifikatskette (certificate chain), die zur Validierung des Endentitätszertifikats verwendet wird. Dies ermöglicht es dem Backend-Ursprungsserver, die Client-Zertifikatsinformationen in seiner Anwendungslogik zu nutzen. Während es zwischen dem TTRP und dem Ursprungsserver zusätzliche Proxies oder Hops (hops) geben kann (möglicherweise sogar mit gegenseitig authentifizierten TLS-Verbindungen zwischen ihnen), ist der Umfang des Client-Cert-Header-Feldes absichtlich darauf beschränkt, dem Ursprungsserver das Zertifikat offenzulegen, das vom ursprünglichen Client in seiner Verbindung zum TTRP präsentiert wurde.