Come trasforma OpenConnect un cookie di accesso in un tunnel?

OpenConnect lega due scambi separati con un solo valore di breve durata: l’accesso web e il tunnel VPN. Il primo scambio è HTTPS ordinario: le credenziali, un giro SAML o un token vanno al gateway, e la risposta porta un cookie di autenticazione. Il secondo scambio presenta quel cookie allo stesso gateway come prova che la fase web è già avvenuta, e solo allora il tunnel sale.

Durante l’accesso non si negozia nulla del tunnel. È la parte che vale la pena capire, perché la maggior parte degli errori di script presuppone che il cookie sia una password da conservare, o una chiave che protegge il traffico, quando in realtà è un biglietto al portatore per una specifica sessione del gateway.

Cosa si scambiano client e gateway, in ordine

La fase di autenticazione somiglia a un normale sito protetto. OpenConnect invia le credenziali dell’utente, o segue il reindirizzamento del gateway verso un fornitore di identità, e il gateway risponde con un documento che incorpora il cookie di autenticazione. Nel protocollo AnyConnect quel valore viaggia in un’intestazione cookie nelle richieste successive, di solito con un nome come webvpn, e il manuale lo tratta come la credenziale che porta avanti la sessione.

La seconda fase è una richiesta CONNECT all’endpoint VPN del gateway con quel cookie allegato. Il gateway lo controlla, assegna un indirizzo, e il client avvia CSTP su TLS, con DTLS come percorso dati opzionale più veloce una volta che la sessione esiste. Solo a questo punto si stabiliscono i parametri del tunnel, le rotte, le impostazioni DNS e le chiavi di traffico della sessione. Il cookie ha fatto passare il client dalla porta; non ha cifrato nulla.

Questa sequenza spiega perché esiste openconnect --authenticate. Eseguitelo e compie la fase web, stampa un piccolo blocco di variabili di shell come COOKIE, HOST, CONNECT_URL e FINGERPRINT, poi esce prima che venga costruito qualsiasi tunnel. Uno script wrapper può quindi avviare la connessione reale con quei valori, ed è esattamente la separazione che serve a un deployment senza interfaccia o in due container.

Il cookie è un portatore di sessione, non una chiave

Trattate il valore come trattereste un identificatore di sessione in un’applicazione web. Chi lo possiede durante la sua vita può chiedere al gateway il tunnel a cui quella sessione ha diritto, quindi la sua segretezza conta. Ma copiarlo non rivela il traffico, perché la riservatezza del tunnel viene dallo handshake TLS e dalle chiavi derivate, non dalla stringa del cookie.

Non è nemmeno una concessione permanente. Il gateway e il fornitore di identità decidono quanto vive la sessione, e un browser che mostra ancora una pagina con accesso effettuato non dice nulla sulla validità della sessione del tunnel. Riconnettersi dopo la scadenza significa ripetere la fase web e produrre un cookie nuovo, e questo è il senso della riautenticazione, non un fastidio da aggirare con l’ingegneria.

Non trattate un cookie come sostituto universale di altre credenziali. Un’asserzione SAML, una password del browser e un cookie emesso da un altro servizio sono oggetti diversi con pubblici diversi, e incollare l’uno nel campo dell’altro di solito fallisce al gateway o, peggio, riesce contro il confine di fiducia sbagliato.

Passare il cookie senza lasciare copie

La consegna meccanica più sicura su Linux è l’input standard. --cookie-on-stdin legge il valore da stdin, così il cookie non appare mai nell’elenco degli argomenti del processo, dove qualsiasi utente locale può leggerlo con ps. Una pipeline che autentica in un processo e alimenta il tunnel in un altro tiene il valore in una pipe invece che in un file o in una variabile d’ambiente.

Gli argomenti e le variabili d’ambiente sono più deboli per motivi diversi. Un argomento è visibile nella tabella dei processi per tutta la vita del client e spesso finisce nella cronologia della shell. Una variabile d’ambiente viene ereditata dai processi figli, e un’unità systemd che la imposta nel file dell’unità conserva il segreto in una configurazione leggibile. Se serve un file, limitatelo all’account di servizio e cancellatelo alla fine della sessione.

Mantenete anche il confine dei privilegi deliberato. Il processo che parla con il fornitore di identità e magari apre un browser dovrebbe girare come l’utente a cui appartiene quell’accesso. Il processo che configura rotte, DNS e dispositivo del tunnel può aver bisogno di più privilegi. Far girare tutto il browser come root perché il suo cookie sia disponibile a un tunnel di proprietà di root è lo scambio sbagliato, e le configurazioni OpenConnect moderne possono passare il valore oltre quel confine in modo esplicito.

La registrazione merita la stessa diffidenza. L’output dettagliato del client, gli script ausiliari e la diagnostica del gateway possono tutti ripetere materiale della richiesta, e non tutti i livelli di log oscurano il cookie. Catturate il più piccolo record di errore che vi serve, tenetelo fuori dai canali condivisi e controllate un campione oscurato prima di allegarlo a un ticket.

Verifica e scadenza nella seconda fase

La seconda fase deve ancora verificare il server. Il FINGERPRINT stampato da --authenticate è un pin del certificato nella forma pin-sha256:, e passarlo alla chiamata del tunnel con --servercert mantiene il controllo ancorato al gateway contro cui vi siete autenticati. Disattivare il controllo dei certificati per semplificare uno script elimina l’unica prova che il cookie viene consegnato all’host previsto.

Quando il gateway rifiuta il cookie, la soluzione è un nuovo giro di autenticazione, non una cache più lunga. Conservate il cookie solo per la durata della connessione, cancellate i file temporanei all’uscita e usate la procedura di rimozione della sessione del fornitore di identità o del gateway quando una sessione viene esposta o un dispositivo va perso. Un cookie in cache non è un’esenzione da MFA.

Prima di automatizzare questo, verificate quattro cose: il tunnel gira con l’account giusto, il cookie arriva da stdin, l’impronta del certificato è bloccata e la sessione viene scartata alla chiusura del tunnel. Se ne manca una, l’automazione ha allargato la fiducia nel cookie invece di riprodurre il flusso manuale.