Cum transformă OpenConnect un cookie de autentificare într-un tunel?

OpenConnect leagă două schimburi separate printr-o singură valoare de scurtă durată: autentificarea web și tunelul VPN. Primul schimb este HTTPS obișnuit: acreditările, o rundă SAML sau un token merg la gateway, iar răspunsul poartă un cookie de autentificare. Al doilea schimb prezintă acel cookie aceluiași gateway ca dovadă că faza web a avut deja loc, și abia atunci se ridică tunelul.

În timpul autentificării nu se negociază nimic despre tunel. Exact aceasta este partea care merită înțeleasă, pentru că majoritatea erorilor din scripturi presupun că cookie-ul este o parolă de stocat sau o cheie care protejează traficul, când de fapt este un bilet la purtător pentru o anumită sesiune a gateway-ului.

Ce schimbă clientul și gateway-ul, în ordine

Faza de autentificare arată ca un site web protejat obișnuit. OpenConnect trimite acreditările utilizatorului sau urmează redirecționarea gateway-ului către un furnizor de identitate, iar gateway-ul răspunde cu un document care încorporează cookie-ul de autentificare. În protocolul AnyConnect acea valoare călătorește într-un antet de cookie la cererile următoare, de obicei sub un nume precum webvpn, iar manualul o tratează ca acreditarea care duce sesiunea mai departe.

A doua fază este o cerere CONNECT către punctul final VPN al gateway-ului cu acel cookie atașat. Gateway-ul îl verifică, atribuie o adresă, iar clientul pornește CSTP peste TLS, cu DTLS ca traseu de date opțional mai rapid odată ce sesiunea există. Doar în acest moment se stabilesc parametrii tunelului, rutele, setările DNS și cheile de trafic ale sesiunii. Cookie-ul a trecut clientul prin ușă; nu a criptat nimic.

Această succesiune explică de ce există openconnect --authenticate. Rulați-l și execută faza web, tipărește un mic bloc de variabile de shell precum COOKIE, HOST, CONNECT_URL și FINGERPRINT, apoi iese înainte de a se construi vreun tunel. Un script înveliș poate porni apoi conexiunea reală cu acele valori, și exact aceasta este separarea de care are nevoie o implementare fără ecran sau cu două containere.

Cookie-ul este un purtător de sesiune, nu o cheie

Tratați valoarea așa cum ați trata un identificator de sesiune într-o aplicație web. Cine o deține pe durata vieții ei poate cere gateway-ului tunelul la care acea sesiune are dreptul, deci confidențialitatea contează. Dar copierea nu dezvăluie traficul, pentru că confidențialitatea tunelului vine din strângerea de mână TLS și din cheile derivate, nu din șirul cookie-ului.

Nu este nici o concesiune permanentă. Gateway-ul și furnizorul de identitate decid cât trăiește sesiunea, iar un browser care încă afișează o pagină autentificată nu spune nimic despre valabilitatea sesiunii tunelului. Reconectarea după expirare înseamnă repetarea fazei web și producerea unui cookie proaspăt, și acesta este sensul reautentificării, nu o pacoste de ocolit prin inginerie.

Nu tratați un cookie ca înlocuitor universal pentru alte acreditări. O aserțiune SAML, o parolă de browser și un cookie emis de alt serviciu sunt obiecte diferite cu publicuri diferite, iar lipirea unuia în câmpul celuilalt eșuează de obicei la gateway sau, mai rău, reușește împotriva graniței de încredere greșite.

Predarea cookie-ului fără a lăsa copii

Cea mai sigură predare mecanică pe Linux este intrarea standard. --cookie-on-stdin citește valoarea din stdin, așa că cookie-ul nu apare niciodată în lista de argumente a procesului, unde orice utilizator local îl poate citi cu ps. O conductă care autentifică într-un proces și alimentează tunelul în altul ține valoarea într-o conductă, nu într-un fișier sau într-o variabilă de mediu.

Argumentele și variabilele de mediu sunt mai slabe din motive diferite. Un argument este vizibil în tabelul de procese pe toată durata de viață a clientului și ajunge adesea în istoricul shell-ului. O variabilă de mediu este moștenită de procesele copil, iar o unitate systemd care o setează în fișierul unității stochează secretul într-o configurație lizibilă. Dacă este nevoie de un fișier, limitați-l la contul de serviciu și ștergeți-l când sesiunea se termină.

Păstrați și granița de privilegii deliberată. Procesul care vorbește cu furnizorul de identitate și poate deschide un browser ar trebui să ruleze ca utilizatorul căruia îi aparține acea autentificare. Procesul care configurează rute, DNS și dispozitivul tunelului poate avea nevoie de mai multe privilegii. Rularea întregului browser ca root pentru ca cookie-ul său să fie disponibil unui tunel deținut de root este schimbul greșit, iar configurațiile moderne OpenConnect pot preda valoarea peste acea graniță în mod explicit.

Jurnalizarea merită aceeași suspiciune. Ieșirea detaliată a clientului, scripturile auxiliare și diagnosticele gateway-ului pot repeta materialul cererii, iar nu fiecare nivel de jurnal redactează cookie-ul. Înregistrați cea mai mică eroare de care aveți nevoie, țineți-o în afara canalelor partajate și verificați un eșantion redactat înainte de a-l atașa unui tichet.

Verificare și expirare în a doua fază

A doua fază trebuie încă să verifice serverul. FINGERPRINT-ul pe care îl tipărește --authenticate este o fixare de certificat în forma pin-sha256:, iar transmiterea lui apelului tunelului cu --servercert menține verificarea ancorată la gateway-ul față de care v-ați autentificat. Oprirea verificării certificatelor pentru a simplifica un script elimină singura dovadă că cookie-ul este predat gazdei dorite.

Când gateway-ul respinge cookie-ul, soluția este o nouă rundă de autentificare, nu un cache mai lung. Păstrați cookie-ul doar pe durata conexiunii, ștergeți fișierele temporare la ieșire și folosiți procesul de eliminare a sesiunii al furnizorului de identitate sau al gateway-ului atunci când o sesiune este expusă ori un dispozitiv se pierde. Un cookie din cache nu este o scutire de la MFA.

Înainte de a automatiza acest lucru, verificați patru lucruri: tunelul rulează sub contul corect, cookie-ul sosește prin stdin, amprenta certificatului este fixată și sesiunea este aruncată când tunelul se închide. Dacă lipsește ceva, automatizarea a lărgit încrederea în cookie în loc să reproducă fluxul manual.