2.4. Processing Rules (Verarbeitungsregeln)

2.4. Processing Rules (Verarbeitungsregeln)

Dieser Abschnitt skizziert die anwendbaren Verarbeitungsregeln für einen TTRP, der eine gegenseitig authentifizierte TLS-Verbindung ausgehandelt hat, um das Client-Zertifikat von dieser Verbindung an die Backend-Ursprungsserver zu übermitteln. Diese Technik soll als Konfigurations- oder Bereitstellungsoption verwendet werden, und die hier beschriebenen Verarbeitungsregeln gelten für Server, die mit aktivierter Option betrieben werden.

Ein TTRP handelt die Verwendung einer gegenseitig authentifizierten TLS-Verbindung mit dem Client aus, wie in [TLS] oder [TLS1.2] beschrieben, und validiert das Client-Zertifikat gemäß seiner Richtlinie und vertrauenswürdigen Zertifizierungsstellen. Jede HTTP-Anfrage auf der zugrunde liegenden TLS-Verbindung wird mit den folgenden Änderungen an den Ursprungsserver weitergeleitet:

1. Das Client-Zertifikat wird in das Client-Cert-Header-Feld der weitergeleiteten Anfrage platziert, wie in Abschnitt 2.2 beschrieben.

2. Falls so konfiguriert, wird die Validierungskette des Client-Zertifikats in das Client-Cert-Chain-Header-Feld der Anfrage platziert, wie in Abschnitt 2.3 beschrieben.

3. Jedes Vorkommen der Client-Cert- oder Client-Cert-Chain-Header-Felder in der ursprünglichen eingehenden Anfrage MUSS vor der Weiterleitung der Anfrage entfernt oder überschrieben werden. Eine eingehende Anfrage, die ein Client-Cert- oder Client-Cert-Chain-Header-Feld aufweist, KANN mit einer HTTP 400-Antwort abgelehnt werden.

Anfragen an den TTRP, die über eine TLS-Verbindung erfolgen, bei der die Verwendung der Client-Zertifikatauthentifizierung nicht ausgehandelt wurde, MÜSSEN durch Entfernen aller Vorkommen der Client-Cert- und Client-Cert-Chain-Header-Felder vor der Weiterleitung der Anfrage an den Backend-Server bereinigt werden.

Backend-Ursprungsserver können dann das Client-Cert-Header-Feld der Anfrage verwenden, um festzustellen, ob die Verbindung vom Client zum TTRP gegenseitig authentifiziert wurde und, wenn ja, das dadurch vom Client präsentierte Zertifikat. Zugriffssteuerungsentscheidungen basierend auf dem Client-Zertifikat (oder dessen Fehlen) können durch Auswahl des Antwortinhalts entsprechend oder mit einer HTTP 403-Antwort übermittelt werden, wenn das Zertifikat für den gegebenen Kontext als inakzeptabel erachtet wird. Beachten Sie, dass TLS-Clients, die sich auf Fehleranzeigen auf der TLS-Ebene für ein inakzeptables Zertifikat verlassen, diese Signale nicht erhalten.

Wenn der Wert des Client-Cert-Anfrage-Header-Feldes verwendet wird, um eine Antwort auszuwählen (z.B. wenn der Antwortinhalt zugriffskontrolliert ist), MUSS die Antwort entweder nicht cacheable sein (z.B. durch Senden von Cache-Control: no-store) oder für eine selektive Wiederverwendung nur für nachfolgende Anfragen mit demselben Client-Cert-Header-Feldwert durch Senden eines Vary: Client-Cert-Antwortheaders bestimmt sein. Wenn ein TTRP auf eine Antwort mit Client-Cert oder Client-Cert-Chain im Vary-Header-Feld (Abschnitt 12.5.5 von [HTTP]) stößt, SOLLTE er verhindern, dass der Benutzeragent die Antwort zwischenspeichert, indem er den Wert des Vary-Antwort-Header-Feldes in * umwandelt.

Forward-Proxies und andere Vermittler DÜRFEN NICHT die Client-Cert- oder Client-Cert-Chain-Header-Felder zu Anfragen hinzufügen oder ein bestehendes Client-Cert- oder Client-Cert-Chain-Header-Feld ändern. Ebenso DÜRFEN Clients das Client-Cert- oder Client-Cert-Chain-Header-Feld NICHT in Anfragen verwenden.