Kako OpenConnect pretvara kolačić za prijavu u tunel?

OpenConnect povezuje dvije odvojene razmjene jednom kratkotrajnom vrijednošću: web prijavu i VPN tunel. Prva razmjena je običan HTTPS: vjerodajnice, SAML kružno putovanje ili token idu prema pristupniku, a odgovor nosi kolačić za autentifikaciju. Druga razmjena predstavlja taj kolačić istom pristupniku kao dokaz da se web faza već dogodila, i tek tada se tunel podiže.

Tijekom prijave ništa o tunelu se ne pregovara. To je dio koji vrijedi razumjeti, jer većina pogrešaka u skriptama pretpostavlja da je kolačić lozinka koju treba spremiti ili ključ koji štiti promet, a on je zapravo nosiva ulaznica za određenu sesiju pristupnika.

Što klijent i pristupnik razmjenjuju, po redu

Faza autentifikacije izgleda kao obično zaštićeno web mjesto. OpenConnect šalje korisničke vjerodajnice ili slijedi preusmjeravanje pristupnika na pružatelja identiteta, a pristupnik odgovara dokumentom koji ugrađuje kolačić za autentifikaciju. U protokolu AnyConnect ta vrijednost putuje u zaglavlju kolačića u sljedećim zahtjevima, obično pod imenom poput webvpn, a priručnik je tretira kao vjerodajnicu koja nosi sesiju naprijed.

Druga faza je CONNECT zahtjev prema VPN krajnjoj točki pristupnika s priloženim kolačićem. Pristupnik ga provjerava, dodjeljuje adresu, a klijent pokreće CSTP preko TLS-a, s DTLS-om kao neobveznim bržim putem podataka kad sesija postoji. Tek se u tom trenutku uspostavljaju parametri tunela, rute, DNS postavke i prometni ključevi sesije. Kolačić je proveo klijenta kroz vrata; nije ništa šifrirao.

Upravo taj slijed objašnjava zašto postoji openconnect --authenticate. Pokrenite ga i on izvodi web fazu, ispisuje mali blok varijabli ljuske poput COOKIE, HOST, CONNECT_URL i FINGERPRINT, a zatim izlazi prije izgradnje ikakvog tunela. Omotačka skripta tada može pokrenuti pravu vezu s tim vrijednostima, što je upravo podjela koju traži bezglava postava ili postava u dva spremnika.

Kolačić je nositelj sesije, a ne ključ

Ponašajte se prema vrijednosti kao prema identifikatoru sesije u web aplikaciji. Tko je drži tijekom njezina života, može od pristupnika zatražiti tunel na koji ta sesija ima pravo, pa je njezina tajnovitost važna. No kopiranje ne otkriva promet, jer povjerljivost tunela dolazi iz TLS rukovanja i izvedenih ključeva, a ne iz niza kolačića.

Ona također nije trajno odobrenje. Pristupnik i pružatelj identiteta odlučuju koliko sesija živi, a preglednik koji još prikazuje prijavljenu stranicu ne govori ništa o tome je li tunelska sesija još valjana. Ponovno povezivanje nakon isteka znači ponavljanje web faze i stvaranje svježeg kolačića, i upravo je to smisao ponovne autentifikacije, a ne dosada koju treba zaobići inženjerski.

Ne tretirajte kolačić kao univerzalnu zamjenu za druge vjerodajnice. SAML tvrdnja, lozinka u pregledniku i kolačić koji je izdala druga usluga različiti su objekti s različitom publikom, a lijepljenje jednoga u polje drugoga obično pada na pristupniku ili, što je gore, uspijeva prema pogrešnoj granici povjerenja.

Predaja kolačića bez ostavljanja kopija

Najsigurnija mehanička predaja na Linuxu je standardni ulaz. --cookie-on-stdin čita vrijednost sa stdin, pa se kolačić nikada ne pojavljuje u popisu argumenata procesa, gdje ga svaki lokalni korisnik može pročitati s ps. Cjevovod koji autentificira u jednom procesu i hrani tunel u drugom drži vrijednost u cijevi, a ne u datoteci ili varijabli okoline.

Argumenti i varijable okoline slabiji su iz različitih razloga. Argument je vidljiv u tablici procesa tijekom života klijenta i često završi u povijesti ljuske. Varijabla okoline nasljeđuje se dječjim procesima, a systemd jedinica koja je postavlja u datoteci jedinice pohranjuje tajnu u čitljivoj konfiguraciji. Ako datoteka ipak mora postojati, ograničite je na servisni račun i uklonite je kad sesija završi.

Držite i granicu privilegija namjernom. Proces koji razgovara s pružateljem identiteta i možda otvara preglednik trebao bi raditi kao korisnik kojemu ta prijava pripada. Proces koji konfigurira rute, DNS i uređaj tunela može trebati više privilegija. Pokretanje cijelog preglednika kao root da bi njegov kolačić bio dostupan tunelu u vlasništvu roota pogrešna je razmjena, a suvremene OpenConnect postave mogu vrijednost izričito prenijeti preko te granice.

Zapisivanje u dnevnik zaslužuje istu sumnju. Opširni izlaz klijenta, pomoćne skripte i dijagnostika pristupnika mogu ponoviti materijal zahtjeva, i ne svaka razina zapisa skriva kolačić. Zabilježite najmanji zapis o pogrešci koji vam treba, držite ga izvan zajedničkih kanala i pregledajte redigirani primjerak prije nego ga priložite zahtjevu.

Provjera i istek u drugoj fazi

Druga faza još mora provjeriti poslužitelj. FINGERPRINT koji ispisuje --authenticate je pin certifikata u obliku pin-sha256:, a njegovo prosljeđivanje pozivu tunela s --servercert drži provjeru usidrenom na pristupniku prema kojem ste se autentificirali. Isključivanje provjere certifikata da bi skripta bila jednostavnija uklanja jedini dokaz da se kolačić predaje namjeravanom računalu.

Kad pristupnik odbije kolačić, rješenje je novi krug autentifikacije, a ne dulja predmemorija. Čuvajte kolačić samo za vrijeme trajanja veze, brišite privremene datoteke pri izlazu i upotrijebite postupak uklanjanja sesije pružatelja identiteta ili pristupnika kad je sesija izložena ili je uređaj izgubljen. Predmemorirani kolačić nije izuzeće od MFA.

Prije automatizacije provjerite četiri stvari: tunel radi pod pravim računom, kolačić stiže preko stdin, otisak certifikata je prikvačen i sesija se odbacuje kad se tunel zatvori. Ako nešto od toga nedostaje, automatizacija je proširila povjerenje u kolačić umjesto da reproducira ručni tijek.