Wie wandelt OpenConnect ein Anmelde-Cookie in einen Tunnel um?

OpenConnect verbindet zwei getrennte Vorgänge mit einem einzigen kurzlebigen Wert: die Web-Anmeldung und den VPN-Tunnel. Der erste Vorgang ist gewöhnliches HTTPS: Anmeldedaten, ein SAML-Rundlauf oder ein Token gehen an das Gateway, und die Antwort enthält ein Authentifizierungs-Cookie. Der zweite Vorgang legt dieses Cookie demselben Gateway als Nachweis vor, dass die Web-Phase bereits stattgefunden hat, und erst dann kommt der Tunnel zustande.

Am Tunnel wird während der Anmeldung nichts ausgehandelt. Das ist der Punkt, den es zu verstehen gilt, denn die meisten Skriptfehler gehen davon aus, das Cookie sei ein Passwort zum Speichern oder ein Schlüssel, der den Verkehr schützt, obwohl es in Wahrheit ein Inhaber-Ticket für eine bestimmte Gateway-Sitzung ist.

Was Client und Gateway der Reihe nach austauschen

Die Authentifizierungsphase sieht aus wie eine normale geschützte Website. OpenConnect sendet die Anmeldedaten des Benutzers oder folgt der Weiterleitung des Gateways zu einem Identitätsanbieter, und das Gateway antwortet mit einem Dokument, das das Auth-Cookie einbettet. Im AnyConnect-Protokoll reist dieser Wert in einem Cookie-Header bei den folgenden Anfragen, üblicherweise unter einem Namen wie webvpn, und das Handbuch behandelt ihn als die Anmeldedaten, die die Sitzung weiterführen.

Die zweite Phase ist eine CONNECT-Anfrage an den VPN-Endpunkt des Gateways mit angehängtem Cookie. Das Gateway prüft es, weist eine Adresse zu, und der Client startet CSTP über TLS, mit DTLS als optionalem schnellerem Datenpfad, sobald die Sitzung besteht. Erst an diesem Punkt werden Tunnelparameter, Routen, DNS-Einstellungen und die Verkehrsschlüssel der Sitzung festgelegt. Das Cookie brachte den Client durch die Tür; verschlüsselt hat es nichts.

Diese Reihenfolge erklärt, warum es openconnect --authenticate gibt. Führt man es aus, durchläuft es die Web-Phase, gibt einen kleinen Block von Shell-Variablen wie COOKIE, HOST, CONNECT_URL und FINGERPRINT aus und beendet sich, bevor ein Tunnel aufgebaut wird. Ein Wrapper-Skript kann dann mit diesen Werten die eigentliche Verbindung starten, was genau der Aufteilung entspricht, die eine headless- oder Zwei-Container-Bereitstellung braucht.

Das Cookie ist ein Sitzungsinhaber, kein Schlüssel

Behandeln Sie den Wert so, wie Sie eine Sitzungs-ID in einer Webanwendung behandeln würden. Wer ihn während seiner Lebensdauer besitzt, kann vom Gateway den Tunnel verlangen, auf den diese Sitzung Anspruch hat, deshalb ist seine Geheimhaltung wichtig. Das Kopieren legt jedoch keinen Verkehr offen, denn die Vertraulichkeit des Tunnels stammt aus dem TLS-Handshake und den abgeleiteten Schlüsseln, nicht aus der Cookie-Zeichenfolge.

Es ist auch keine dauerhafte Gewährung. Gateway und Identitätsanbieter entscheiden, wie lange die Sitzung lebt, und ein Browser, der noch eine angemeldete Seite zeigt, sagt nichts darüber aus, ob die Tunnel-Sitzung noch gültig ist. Nach dem Ablauf bedeutet erneutes Verbinden, die Web-Phase zu wiederholen und ein frisches Cookie zu erzeugen; genau das ist der Sinn der Reauthentifizierung und keine lästige Hürde, um die man herumkonstruieren müsste.

Behandeln Sie ein Cookie nicht als universellen Ersatz für andere Anmeldedaten. Eine SAML-Assertion, ein Browser-Passwort und ein von einem anderen Dienst ausgestelltes Cookie sind verschiedene Objekte mit verschiedenen Adressaten, und wer das eine in das Feld des anderen einfügt, scheitert meist am Gateway oder, schlimmer, hat Erfolg gegenüber der falschen Vertrauensgrenze.

Das Cookie weitergeben, ohne Kopien zu hinterlassen

Die sicherste mechanische Übergabe unter Linux ist die Standardeingabe. --cookie-on-stdin liest den Wert aus stdin, sodass das Cookie nie in der Argumentliste des Prozesses erscheint, wo jeder lokale Benutzer es mit ps lesen könnte. Eine Pipeline, die in einem Prozess authentifiziert und den Tunnel in einem anderen speist, hält den Wert in einer Pipe statt in einer Datei oder einer Umgebungsvariablen.

Argumente und Umgebungsvariablen sind aus unterschiedlichen Gründen schwächer. Ein Argument ist für die Lebensdauer des Clients in der Prozesstabelle sichtbar und landet oft in der Shell-Historie. Eine Umgebungsvariable wird an Kindprozesse vererbt, und eine systemd-Unit, die sie in der Unit-Datei setzt, speichert das Geheimnis in einer lesbaren Konfiguration. Wenn es eine Datei sein muss, beschränken Sie sie auf das Dienstkonto und entfernen Sie sie, wenn die Sitzung endet.

Halten Sie auch die Privilegiengrenze bewusst. Der Prozess, der mit dem Identitätsanbieter spricht und womöglich einen Browser öffnet, sollte als der Benutzer laufen, dem diese Anmeldung gehört. Der Prozess, der Routen, DNS und das Tunnelgerät konfiguriert, braucht möglicherweise mehr Rechte. Den ganzen Browser als Root laufen zu lassen, damit sein Cookie einem root-eigenen Tunnel zur Verfügung steht, ist der falsche Tausch, und moderne OpenConnect-Setups können den Wert ausdrücklich über diese Grenze hinweg übergeben.

Auch die Protokollierung verdient dasselbe Misstrauen. Ausführliche Client-Ausgaben, Hilfsskripte und Gateway-Diagnosen können alle Anfragematerial wiederholen, und nicht jede Protokollstufe schwärzt das Cookie. Erfassen Sie den kleinsten Fehlerdatensatz, den Sie brauchen, halten Sie ihn aus gemeinsamen Kanälen heraus, und prüfen Sie eine geschwärzte Stichprobe, bevor Sie sie einem Ticket anhängen.

Prüfung und Ablauf in der zweiten Phase

Die zweite Phase muss den Server weiterhin prüfen. Der FINGERPRINT, den --authenticate ausgibt, ist ein Zertifikats-Pin in der Form pin-sha256:, und wenn man ihn mit --servercert an den Tunnelaufruf übergibt, bleibt die Prüfung auf das Gateway verankert, gegen das man sich authentifiziert hat. Die Zertifikatsprüfung abzuschalten, um ein Skript zu vereinfachen, beseitigt den einzigen Beweis dafür, dass das Cookie an den beabsichtigten Host geht.

Wenn das Gateway das Cookie ablehnt, ist die Lösung eine neue Authentifizierungsrunde und kein längerer Cache. Speichern Sie das Cookie nur für die Lebensdauer der Verbindung, löschen Sie temporäre Dateien beim Beenden, und nutzen Sie den Sitzungsentfernungsprozess des Identitätsanbieters oder Gateways, wenn eine Sitzung offengelegt wird oder ein Gerät verloren geht. Ein zwischengespeichertes Cookie ist keine Befreiung von MFA.

Bevor Sie das automatisieren, prüfen Sie vier Dinge: Der Tunnel läuft unter dem richtigen Konto, das Cookie kommt über stdin, der Zertifikats-Fingerabdruck ist gepinnt, und die Sitzung wird verworfen, wenn der Tunnel schließt. Fehlt eines davon, hat die Automatisierung das Vertrauen in das Cookie erweitert, statt den manuellen Ablauf nachzubilden.