Hoe makket OpenConnect in oanmeldkoekje ta in tunnel?

OpenConnect ferbynt twa aparte útwikselings mei ien koart libjende wearde: de web-oanmelding en de VPN-tunnel. De earste útwikseling is gewoane HTTPS: oanmeldgegevens, in SAML-rûnreis of in token geane nei de gateway, en it antwurd draacht in autentikaasjekoekje. De twadde útwikseling presintearret dat koekje oan deselde gateway as bewiis dat de webfaze al bard is, en pas dan komt de tunnel omheech.

By de oanmelding wurdt neat oer de tunnel ûnderhannele. Dat is it part dat it wurdich is om te begripen, want de measte skriptflaters geane derfan út dat it koekje in wachtwurd is om te bewarjen, of in kaai dy’t ferkear beskermet, wylst it eins in dragerstsjett is foar in beskate gatewaysesje.

Wat de klient en de gateway yn folchoarder útwikselje

De autentikaasjefaze liket op in gewoane beskerme webside. OpenConnect stjoert de oanmeldgegevens fan de brûker, of folget de trochstjoering fan de gateway nei in identiteitsferstrekker, en de gateway antwurdet mei in dokumint dat it autentikaasjekoekje ynbêdet. Yn it AnyConnect-protokol reizget dy wearde yn in koekjekop by de folgjende oanfragen, meastentiids ûnder in namme as webvpn, en de hânlieding behannelt it as it gegeven dat de sesje fuortdraacht.

De twadde faze is in CONNECT-oanfraach nei it VPN-einpunt fan de gateway mei dat koekje taheakke. De gateway kontrolearret it, jout in adres ta, en de klient start CSTP oer TLS, mei DTLS as opsjonele fluggere datapad sadree’t de sesje bestiet. Pas op dit punt wurde tunnelparameters, rûtes, DNS-ynstellingen en de ferkearskaaien fan de sesje fêststeld. It koekje krige de klient troch de doar; it fersiferet neat.

Dizze folchoarder ferklearret wêrom’t openconnect --authenticate bestiet. Rin it, en it docht de webfaze, printsje in lyts blok shell-fariabelen lykas COOKIE, HOST, CONNECT_URL en FINGERPRINT, en giet dan fuort foar’t der in tunnel boud wurdt. In wrapper-skript kin dan de echte ferbining mei dy wearden starte, en dat is krekt de splitsing dy’t in headless- of twa-kontener-ynset nedich hat.

It koekje is in sesjedrager, gjin kaai

Behannelje de wearde sa’t jo in sesje-ID yn in webapplikaasje behannelje soene. Wa’t it by de libbensdoer hat, kin by de gateway de tunnel freegje dêr’t dy sesje rjocht op hat, dus de geheimhâlding is wichtich. Mar it kopiearjen iepenbieret gjin ferkear, want de fertroulikheid fan de tunnel komt út de TLS-hânskodding en de ôflate kaaien, net út de koekjereeks.

It is ek gjin permaninte tastimming. De gateway en de identiteitsferstrekker beslute hoelang’t de sesje libbet, en in browser dy’t noch in oanmelde side toant seit neat oer oft de tunnelsesje noch jildich is. Opnij ferbine nei ferrin betsjut de webfaze werhelje en in farsk koekje meitsje, en dat is krekt it doel fan opnij autentisearjen, net in pleach om omhinne te wurkjen.

Behannelje in koekje net as in universele ferfanging foar oare oanmeldgegevens. In SAML-befêsting, in browserwachtwurd en in koekje fan in oare tsjinst binne ferskate objekten mei ferskate publyk, en it iene yn it fjild fan it oare plakke mislearret meastentiids by de gateway of, slimmer, slagget tsjin de ferkearde fertrouwensgrins.

It koekje trochjaan sûnder kopyen efter te litten

De feilichste meganyske oerdracht op Linux is standertynfier. --cookie-on-stdin lêst de wearde fan stdin, sadat it koekje nea yn ‘e argumintlist fan it proses ferskynt, dêr’t elke lokale brûker it mei ps lêze kin. In pipeline dy’t yn it iene proses autentisearret en de tunnel yn in oar fuorret, hâldt de wearde yn in buis ynstee fan yn in bestân of omjouwingsfariabele.

Arguminten en omjouwingsfariabelen binne om ferskate redenen swakker. In argumint is sichtber yn ‘e prosestabel by de hiele libbensdoer fan de klient en bedarret faak yn ‘e shell-skiednis. In omjouwingsfariabele wurdt erfd troch bernprosessen, en in systemd-ienheid dy’t it yn it ienheidsbestân set, bewarret it geheim yn in lêsbere konfiguraasje. As in bestân needsaaklik is, behein it dan ta it tsjinstaccount en smyt it fuort as de sesje einiget.

Hâld de privileezjegrins ek bewust. It proses dat mei de identiteitsferstrekker praat en miskien in browser iepenet, moat rinne as de brûker oan wa’t dy oanmelding heart. It proses dat rûtes, DNS en it tunnelapparaat konfigurearret, hat miskien mear privileezjes nedich. De hiele browser as root rinne litte sadat syn koekje beskikber is foar in tunnel fan root, is de ferkearde ruil, en moderne OpenConnect-ynsetten kinne de wearde eksplisyt oer dy grins jouwe.

Lochfêstlizzen fertsjinnet itselde wantrouwen. Utfierige klientútfier, helperskripten en gatewaydiagnostyk kinne allegear oanfraachmateriaal werhelje, en net elk lochnivo ferberget it koekje. Fêstlizzie it lytste flaterrecord dat jo nedich hawwe, hâld it bûten dielde kanalen en kontrolearje in ferburgen meunster foar’t jo it oan in ticket taheakje.

Ferifikaasje en ferrin yn ‘e twadde faze

De twadde faze moat de server noch ferifiearje. De FINGERPRINT dy’t --authenticate print, is in sertifikaatpin yn ‘e foarm pin-sha256:, en it trochjaan oan ‘e tunneloanroppen mei --servercert hâldt de kontrôle fêst oan ‘e gateway dêr’t jo jo by autentisearre hawwe. It útskeakeljen fan sertifikaatkontrôle om in skript ienfâldiger te meitsjen, hellet it iennichste bewiis fuort dat it koekje oan de bedoelde host jûn wurdt.

As de gateway it koekje ôfwiist, is de oplossing in nije autentikaasjerûn, net in langer cache. Bewarje it koekje allinnich foar de libbensdoer fan ‘e ferbining, smyt tydlike bestannen by it ôfsluten fuort, en brûk it sesjeferwideringsproses fan ‘e identiteitsferstrekker of gateway as in sesje bleatlein wurdt of in apparaat ferlern giet. In cachet koekje is gjin frijstelling fan MFA.

Kontrolearje fjouwer dingen foar’t jo dit automatisearje: de tunnel rint ûnder it goede account, it koekje komt oer stdin, de sertifikaatfingerprint is fêstset, en de sesje wurdt fuortgoaid as de tunnel slút. As ien fan dy ûntbrekt, hat de automatisearring it fertrouwen yn it koekje ferbrede ynstee fan ‘e hânmjittige stream te reprodusearjen.