Hoe maakt OpenConnect van een aanmeldcookie een tunnel?

OpenConnect verbindt twee afzonderlijke uitwisselingen met één kortlevende waarde: de webaanmelding en de VPN-tunnel. De eerste uitwisseling is gewone HTTPS: inloggegevens, een SAML-rondreis of een token gaan naar de gateway, en het antwoord draagt een authenticatiecookie. De tweede uitwisseling toont die cookie aan dezelfde gateway als bewijs dat de webfase al heeft plaatsgevonden, en pas dan komt de tunnel omhoog.

Tijdens het aanmelden wordt niets over de tunnel onderhandeld. Dat is het deel dat het begrijpen waard is, omdat de meeste scriptfouten aannemen dat de cookie een wachtwoord is om op te slaan, of een sleutel die het verkeer beschermt, terwijl het in werkelijkheid een dragerticket is voor een specifieke gatewaysessie.

Wat de client en de gateway achtereenvolgens uitwisselen

De authenticatiefase ziet eruit als een gewone beveiligde website. OpenConnect stuurt de inloggegevens van de gebruiker, of volgt de omleiding van de gateway naar een identiteitsprovider, en de gateway antwoordt met een document dat het authenticatiecookie insluit. In het AnyConnect-protocol reist die waarde in een cookieheader mee op de volgende verzoeken, meestal onder een naam als webvpn, en de handleiding behandelt hem als de inloggegevens die de sessie verder dragen.

De tweede fase is een CONNECT-verzoek aan het VPN-eindpunt van de gateway met die cookie bijgevoegd. De gateway controleert hem, wijst een adres toe, en de client start CSTP over TLS, met DTLS als optioneel sneller datapad zodra de sessie bestaat. Pas op dit punt worden de tunnelparameters, routes, DNS-instellingen en de verkeerssleutels van de sessie vastgelegd. De cookie loodste de client door de deur; hij versleutelde niets.

Deze volgorde verklaart waarom openconnect --authenticate bestaat. Voer het uit en het doet de webfase, print een klein blok shellvariabelen zoals COOKIE, HOST, CONNECT_URL en FINGERPRINT, en stopt dan voordat er een tunnel wordt gebouwd. Een wrapperscript kan daarna de echte verbinding met die waarden starten, en dat is precies de splitsing die een headless of twee-container-implementatie nodig heeft.

De cookie is een sessiedrager, geen sleutel

Behandel de waarde zoals je een sessie-ID in een webapplicatie zou behandelen. Wie hem tijdens zijn levensduur heeft, kan bij de gateway de tunnel opvragen waar die sessie recht op heeft, dus geheimhouding is belangrijk. Maar kopiëren onthult geen verkeer, omdat de vertrouwelijkheid van de tunnel uit de TLS-handshake en de afgeleide sleutels komt, niet uit de cookiestring.

Het is ook geen permanente toestemming. De gateway en de identiteitsprovider bepalen hoe lang de sessie leeft, en een browser die nog een aangemelde pagina toont, zegt niets over of de tunnelsessie nog geldig is. Opnieuw verbinden na verloop betekent de webfase herhalen en een verse cookie maken, en dat is precies het doel van herauthenticatie, geen last die je technisch zou moeten omzeilen.

Behandel een cookie niet als universele vervanging voor andere inloggegevens. Een SAML-bewering, een browserwachtwoord en een cookie van een andere dienst zijn verschillende objecten met verschillende doelgroepen, en het ene in het veld van het andere plakken mislukt meestal bij de gateway of, erger, slaagt tegen de verkeerde vertrouwensgrens.

De cookie doorgeven zonder kopieën achter te laten

De veiligste mechanische overdracht op Linux is standaardinvoer. --cookie-on-stdin leest de waarde van stdin, zodat de cookie nooit in de argumentlijst van het proces verschijnt, waar elke lokale gebruiker hem met ps kan lezen. Een pijplijn die in het ene proces authenticeert en de tunnel in een ander voedt, houdt de waarde in een pijp in plaats van in een bestand of een omgevingsvariabele.

Argumenten en omgevingsvariabelen zijn om verschillende redenen zwakker. Een argument is zichtbaar in de procestabel gedurende de hele levensduur van de client en belandt vaak in de shellgeschiedenis. Een omgevingsvariabele wordt door kindprocessen geërfd, en een systemd-unit die hem in het unitbestand zet, bewaart het geheim in een leesbare configuratie. Als een bestand echt nodig is, beperk het dan tot het serviceaccount en verwijder het wanneer de sessie eindigt.

Houd ook de privilegesgrens bewust. Het proces dat met de identiteitsprovider praat en misschien een browser opent, zou moeten draaien als de gebruiker aan wie die aanmelding toebehoort. Het proces dat routes, DNS en het tunnelapparaat configureert, heeft mogelijk meer privileges nodig. De hele browser als root draaien zodat zijn cookie beschikbaar is voor een tunnel die van root is, is de verkeerde ruil, en moderne OpenConnect-opstellingen kunnen de waarde expliciet over die grens heen geven.

Logging verdient hetzelfde wantrouwen. Uitgebreide clientuitvoer, hulpscripts en gatewaydiagnostiek kunnen allemaal verzoekmateriaal herhalen, en niet elk logniveau verbergt de cookie. Leg de kleinste foutregistratie vast die je nodig hebt, houd die buiten gedeelde kanalen, en controleer een verborgen voorbeeld voordat je het aan een ticket hangt.

Verificatie en verloop in de tweede fase

De tweede fase moet de server nog steeds verifiëren. De FINGERPRINT die --authenticate afdrukt, is een certificaatpin in de vorm pin-sha256:, en hem met --servercert aan de tunnelaanroep geven houdt de controle verankerd aan de gateway waartegen je je hebt geauthenticeerd. Certificaatcontrole uitzetten om een script eenvoudiger te maken, verwijdert het enige bewijs dat de cookie aan de bedoelde host wordt afgegeven.

Wanneer de gateway de cookie weigert, is de oplossing een nieuwe authenticatieronde, geen langere cache. Bewaar de cookie alleen voor de duur van de verbinding, verwijder tijdelijke bestanden bij het afsluiten, en gebruik het sessieverwijderingsproces van de identiteitsprovider of de gateway wanneer een sessie wordt blootgesteld of een apparaat verloren gaat. Een gecachte cookie is geen vrijstelling van MFA.

Controleer vier dingen voordat je dit automatiseert: de tunnel draait onder het juiste account, de cookie komt binnen via stdin, de vingerafdruk van het certificaat is vastgezet, en de sessie wordt weggegooid wanneer de tunnel sluit. Als een daarvan ontbreekt, heeft de automatisering het vertrouwen in de cookie verbreed in plaats van de handmatige stroom te reproduceren.