Hoe verander OpenConnect ’n aanmeldkoekie in ’n tonnel?

OpenConnect koppel twee afsonderlike uitruilings met een kortstondige waarde: die web-aanmelding en die VPN-tonnel. Die eerste uitruiling is gewone HTTPS: geloofsbriewe, ’n SAML-omrit of ’n teken gaan na die poort, en die antwoord dra ’n verifikasiekoekie. Die tweede uitruiling bied daardie koekie aan dieselfde poort as bewys dat die web-fase reeds plaasgevind het, en eers dan kom die tonnel op.

Nikste oor die tonnel word tydens die aanmelding beding nie. Dit is die deel wat werd is om te verstaan, want die meeste skripfoute aanvaar dat die koekie ’n wagwoord is om te stoor, of ’n sleutel wat verkeer beskerm, terwyl dit eintlik ’n draerkaartjie vir ’n spesifieke poortsessie is.

Wat die kliënt en die poort in volgorde uitruil

Die verifikasiefase lyk soos ’n gewone beskermde webwerf. OpenConnect stuur die gebruiker se geloofsbriewe, of volg die poort se aanstuur na ’n identiteitsverskaffer, en die poort antwoord met ’n dokument wat die verifikasiekoekie insluit. In die AnyConnect-protokol reis daardie waarde in ’n koekiekop by die volgende versoeke, gewoonlik onder ’n naam soos webvpn, en die handleiding behandel dit as die geloofsbrief wat die sessie vorentoe dra.

Die tweede fase is ’n CONNECT-versoek aan die poort se VPN-eindpunt met daardie koekie aangeheg. Die poort kontroleer dit, wys ’n adres toe, en die kliënt begin CSTP oor TLS, met DTLS as ’n opsionele vinniger datapad sodra die sessie bestaan. Eers op hierdie punt word tonnelparameters, roetes, DNS-instellings en die sessie se verkeersleutels vasgestel. Die koekie het die kliënt deur die deur gekry; dit het niks versleutel nie.

Daardie volgorde verduidelik waarom openconnect --authenticate bestaan. Voer dit uit, en dit doen die web-fase, druk ’n klein blok veranderlikes soos COOKIE, HOST, CONNECT_URL en FINGERPRINT uit, en stop voordat enige tonnel gebou word. ’n Omhulskrip kan dan die werklike verbinding met daardie waardes begin, wat presies die splitsing is wat ’n kop-lose of twee-houer ontplooiing nodig het.

Die koekie is ’n sessiedraer, nie ’n sleutel nie

Behandel die waarde soos jy ’n sessie-ID in ’n webtoepassing sou behandel. Wie dit gedurende sy leeftyd hou, kan by die poort die tonnel aanvra waarop daardie sessie geregtig is, so die geheimhouding daarvan maak saak. Maar om dit te kopieer openbaar nie verkeer nie, want die tonnel se vertroulikheid kom uit die TLS-handdruk en die afgeleide sleutels, nie uit die koekiereeks nie.

Dit is ook nie ’n permanente toestemming nie. Die poort en die identiteitsverskaffer besluit hoe lank die sessie leef, en ’n blaaier wat nog ’n aangemelde bladsy wys, sê niks oor of die tonnelsessie nog geldig is nie. Om na verstryking weer te koppel, beteken om die web-fase te herhaal en ’n vars koekie te produseer, en dit is juis die punt van herverifikasie, nie ’n lastigheid om omheen te werk nie.

Moenie ’n koekie as ’n universele plaasvervanger vir ander geloofsbriewe behandel nie. ’n SAML-bewering, ’n blaaierwagwoord en ’n koekie wat deur ’n ander diens uitgereik is, is verskillende objekte met verskillende gehore, en om die een in die ander se veld te plak, misluk gewoonlik by die poort of, erger, slaag teen die verkeerde vertrouensgrens.

Die koekie deurgee sonder om afskrifte te los

Die veiligste meganiese oorhandiging op Linux is standaardinvoer. --cookie-on-stdin lees die waarde uit stdin, sodat die koekie nooit in die proses se argumentlys verskyn waar enige plaaslike gebruiker dit met ps kan lees nie. ’n Pyplyn wat in een proses verifieer en die tonnel in ’n ander voed, hou die waarde in ’n pyp eerder as in ’n lêer of ’n omgewingsveranderlike.

Argumente en omgewingsveranderlikes is om verskillende redes swakker. ’n Argument is sigbaar in die prosestabel vir die leeftyd van die kliënt en beland dikwels in die dopgeskiedenis. ’n Omgewingsveranderlike word aan kindprosesse geërf, en ’n systemd-eenheid wat dit in die eenheidlêer stel, stoor die geheim in ’n leesbare konfigurasie. As dit ’n lêer moet wees, beperk dit tot die diensrekening en verwyder dit wanneer die sessie eindig.

Hou ook die privilejiegrens doelbewus. Die proses wat met die identiteitsverskaffer praat en moontlik ’n blaaier oopmaak, moet as die gebruiker loop aan wie daardie aanmelding behoort. Die proses wat roetes, DNS en die tonneltoestel instel, het dalk meer bevoegdheid nodig. Om die hele blaaier as root te laat loop sodat sy koekie vir ’n root-besitte tonnel beskikbaar is, is die verkeerde ruil, en moderne OpenConnect-opstellings kan die waarde uitdruklik oor daardie grens heen gee.

Logging verdien dieselfde agterdog. Uitgebreide kliëntuitset, hulpskripte en poortdiagnostiek kan alles versoekmateriaal herhaal, en nie elke logvlak redigeer die koekie nie. Teken die kleinste foutrekord op wat jy nodig het, hou dit uit gedeelde kanale, en kyk na ’n geredigeerde monster voordat jy dit aan ’n kaartjie heg.

Verifikasie en verstryking in die tweede fase

Die tweede fase moet die bediener steeds verifieer. Die FINGERPRINT wat --authenticate uitdruk, is ’n sertifikaatpen in die vorm pin-sha256:, en om dit met --servercert aan die tonneloproep te gee, hou die kontrole geanker aan die poort waarteen jy geverifieer het. Om sertifikaatkontrole af te skakel om ’n skrip eenvoudiger te maak, verwyder die enigste bewys dat die koekie aan die beoogde gasheer gegee word.

Wanneer die poort die koekie verwerp, is die oplossing ’n nuwe verifikasieronde, nie ’n langer kas nie. Stoor die koekie net vir die leeftyd van die verbinding, verwyder tydelike lêers by afsluiting, en gebruik die identiteitsverskaffer of poort se sessieverwyderingsproses wanneer ’n sessie blootgestel word of ’n toestel verloor gaan. ’n Gekaste koekie is nie ’n vrystelling van MFA nie.

Voordat jy dit outomatiseer, verifieer vier dinge: die tonnel loop onder die regte rekening, die koekie kom oor stdin, die sertifikaatvingerafdruk is vasgepen, en die sessie word weggegooi wanneer die tonnel sluit. As enige een daarvan ontbreek, het die outomatisering die vertroue in die koekie verbreed eerder as om die handmatige vloei te herhaal.