Comment OpenConnect transforme-t-il un cookie de connexion en tunnel ?

OpenConnect relie deux échanges distincts par une seule valeur de courte durée : la connexion web et le tunnel VPN. Le premier échange est du HTTPS ordinaire : les identifiants, un aller-retour SAML ou un jeton partent vers la passerelle, et la réponse porte un cookie d’authentification. Le second échange présente ce cookie à la même passerelle comme preuve que la phase web a déjà eu lieu, et c’est seulement alors que le tunnel monte.

Rien du tunnel n’est négocié pendant la connexion. C’est la partie qui mérite d’être comprise, car la plupart des erreurs de script supposent que le cookie est un mot de passe à stocker, ou une clé qui protège le trafic, alors qu’il est en réalité un ticket au porteur pour une session de passerelle donnée.

Ce que le client et la passerelle échangent, dans l’ordre

La phase d’authentification ressemble à un site web protégé ordinaire. OpenConnect envoie les identifiants de l’utilisateur, ou suit la redirection de la passerelle vers un fournisseur d’identité, et la passerelle répond par un document qui intègre le cookie d’authentification. Dans le protocole AnyConnect, cette valeur voyage dans un en-tête de cookie lors des requêtes suivantes, généralement sous un nom comme webvpn, et le manuel la traite comme l’identifiant qui porte la session.

La seconde phase est une requête CONNECT vers le point de terminaison VPN de la passerelle, avec ce cookie joint. La passerelle le vérifie, attribue une adresse, et le client démarre CSTP sur TLS, avec DTLS comme chemin de données optionnel plus rapide une fois la session établie. C’est seulement à ce moment que les paramètres du tunnel, les routes, la configuration DNS et les clés de trafic de la session sont établis. Le cookie a fait passer le client par la porte ; il n’a rien chiffré.

Cette séquence explique pourquoi openconnect --authenticate existe. Lancez-le : il effectue la phase web, imprime un petit bloc de variables de shell comme COOKIE, HOST, CONNECT_URL et FINGERPRINT, puis quitte avant qu’un tunnel ne soit construit. Un script d’enveloppe peut ensuite démarrer la vraie connexion avec ces valeurs, ce qui est exactement la séparation dont a besoin un déploiement sans interface ou en deux conteneurs.

Le cookie est un porteur de session, pas une clé

Traitez la valeur comme vous traiteriez un identifiant de session dans une application web. Quiconque le détient pendant sa durée de vie peut demander à la passerelle le tunnel auquel cette session a droit, donc sa confidentialité compte. Mais le copier ne révèle pas le trafic, car la confidentialité du tunnel vient de la poignée de main TLS et des clés dérivées, pas de la chaîne du cookie.

Ce n’est pas non plus une autorisation permanente. La passerelle et le fournisseur d’identité décident combien de temps vit la session, et un navigateur qui affiche encore une page connectée ne dit rien de la validité de la session du tunnel. Se reconnecter après expiration signifie répéter la phase web et produire un cookie neuf, et c’est là le sens de la réauthentification, pas une gêne à contourner par l’ingénierie.

Ne traitez pas un cookie comme un substitut universel aux autres identifiants. Une assertion SAML, un mot de passe de navigateur et un cookie émis par un autre service sont des objets différents avec des audiences différentes, et coller l’un dans le champ de l’autre échoue généralement à la passerelle ou, pire, réussit contre la mauvaise frontière de confiance.

Transmettre le cookie sans laisser de copies

La remise mécanique la plus sûre sous Linux est l’entrée standard. --cookie-on-stdin lit la valeur sur stdin, si bien que le cookie n’apparaît jamais dans la liste d’arguments du processus, où tout utilisateur local peut le lire avec ps. Un pipeline qui authentifie dans un processus et alimente le tunnel dans un autre garde la valeur dans un tuyau plutôt que dans un fichier ou une variable d’environnement.

Les arguments et les variables d’environnement sont plus faibles pour des raisons différentes. Un argument est visible dans la table des processus pendant toute la vie du client et finit souvent dans l’historique du shell. Une variable d’environnement est héritée par les processus enfants, et une unité systemd qui la définit dans le fichier d’unité stocke le secret dans une configuration lisible. Si un fichier est indispensable, limitez-le au compte de service et supprimez-le à la fin de la session.

Gardez aussi la frontière de privilèges délibérée. Le processus qui parle au fournisseur d’identité et ouvre peut-être un navigateur devrait tourner sous l’utilisateur à qui appartient cette connexion. Le processus qui configure les routes, le DNS et le périphérique du tunnel peut avoir besoin de plus de privilèges. Faire tourner tout le navigateur en root pour que son cookie soit disponible à un tunnel possédé par root est le mauvais compromis, et les configurations OpenConnect modernes peuvent transmettre la valeur au-delà de cette frontière explicitement.

La journalisation mérite la même méfiance. La sortie détaillée du client, les scripts auxiliaires et les diagnostics de la passerelle peuvent tous répéter des éléments de la requête, et tous les niveaux de journal ne masquent pas le cookie. Capturez le plus petit enregistrement d’erreur dont vous avez besoin, gardez-le hors des canaux partagés et vérifiez un échantillon masqué avant de le joindre à un ticket.

Vérification et expiration dans la seconde phase

La seconde phase doit encore vérifier le serveur. Le FINGERPRINT imprimé par --authenticate est une épingle de certificat au format pin-sha256:, et le transmettre à l’appel du tunnel avec --servercert maintient la vérification ancrée à la passerelle contre laquelle vous vous êtes authentifié. Désactiver la vérification des certificats pour simplifier un script supprime la seule preuve que le cookie est remis à l’hôte prévu.

Quand la passerelle rejette le cookie, la solution est une nouvelle passe d’authentification, pas un cache plus long. Ne conservez le cookie que pendant la durée de la connexion, supprimez les fichiers temporaires à la sortie et utilisez la procédure de retrait de session du fournisseur d’identité ou de la passerelle lorsqu’une session est exposée ou qu’un appareil est perdu. Un cookie mis en cache n’est pas une exemption de MFA.

Avant d’automatiser cela, vérifiez quatre choses : le tunnel tourne sous le bon compte, le cookie arrive par stdin, l’empreinte du certificat est épinglée et la session est abandonnée à la fermeture du tunnel. S’il en manque une, l’automatisation a élargi la confiance dans le cookie au lieu de reproduire le flux manuel.