OpenConnect hubadilishaje kuki ya kuingia kuwa handaki?

OpenConnect huunganisha mabadilishano mawili tofauti kwa thamani moja ya muda mfupi: kuingia mtandaoni na handaki la VPN. Mabadilishano ya kwanza ni HTTPS ya kawaida: vitambulisho, safari ya SAML au tokeni huenda kwa lango, na jibu hubeba kuki ya uthibitishaji. Mabadilishano ya pili huwasilisha kuki hiyo kwa lango hilo hilo kama uthibitisho kwamba awamu ya mtandao ilishatokea, na ndipo tu handaki huinuka.

Wakati wa kuingia hakuna kinachojadiliwa kuhusu handaki. Hii ndiyo sehemu inayofaa kueleweka, kwa sababu makosa mengi ya script hudhani kuki ni neno la siri la kuhifadhi, au ufunguo unaolinda trafiki, ilhali kwa kweli ni tikiti ya mbebaji kwa kipindi maalum cha lango.

Mteja na lango hubadilishana nini, kwa mpangilio

Awamu ya uthibitishaji inaonekana kama tovuti ya kawaida iliyolindwa. OpenConnect hutuma vitambulisho vya mtumiaji, au hufuata uelekezaji upya wa lango kwa mtoa utambulisho, na lango hujibu kwa hati inayojumuisha kuki ya uthibitishaji. Katika itifaki ya AnyConnect thamani hiyo husafiri katika kichwa cha kuki kwenye maombi yanayofuata, kwa kawaida chini ya jina kama webvpn, na mwongozo huichukulia kama kitambulisho kinachobeba kipindi mbele.

Awamu ya pili ni ombi la CONNECT kwa mwisho wa VPN wa lango likiwa na kuki hiyo iliyoambatishwa. Lango huikagua, hutoa anwani, na mteja huanzisha CSTP juu ya TLS, na DTLS ni njia ya data ya haraka zaidi ya hiari mara kipindi kinapokuwepo. Ni wakati huu tu ambapo vigezo vya handaki, njia, mipangilio ya DNS na funguo za trafiki za kipindi huanzishwa. Kuki ilimpeleka mteja kupitia mlango; haikusimba kitu.

Mpangilio huu unaeleza kwa nini openconnect --authenticate ipo. Iendeshe, na hufanya awamu ya mtandao, huchapisha kizuizi kidogo cha vibadala vya shell kama COOKIE, HOST, CONNECT_URL na FINGERPRINT, kisha hutoka kabla handaki lolote kujengwa. Script ya kufunga inaweza kisha kuanzisha muunganisho halisi na thamani hizo, na hiyo ndiyo mgawanyiko hasa unaohitajika kwa usambazaji usio na kichwa au wa vyombo viwili.

Kuki ni mbebaji wa kipindi, sio ufunguo

Shughulikia thamani kama ungeishughulikia kitambulisho cha kipindi katika programu ya mtandao. Yeyote aliye nayo katika maisha yake anaweza kuomba lango handaki ambalo kipindi hicho kinastahili, kwa hiyo usiri wake ni muhimu. Lakini kunakili hakufichui trafiki, kwa sababu usiri wa handaki hutoka kwa kupeana mikono kwa TLS na funguo zinazotokana, sio kwa mfuatano wa kuki.

Pia sio idhini ya kudumu. Lango na mtoa utambulisho huamua kipindi kinaishi kwa muda gani, na kivinjari kinachoendelea kuonyesha ukurasa ulioingiwa hakisemi chochote kuhusu kama kipindi cha handaki bado ni halali. Kuunganisha tena baada ya kuisha kuna maana ya kurudia awamu ya mtandao na kutoa kuki mpya, na hicho ndicho lengo la uthibitishaji upya, sio usumbufu wa kuepukwa kwa uhandisi.

Usichukulie kuki kama mbadala wa jumla kwa vitambulisho vingine. Dai la SAML, neno la siri la kivinjari na kuki iliyotolewa na huduma nyingine ni vitu tofauti vyenye hadhira tofauti, na kubandika kimoja kwenye uwanja wa kingine kwa kawaida hushindwa kwenye lango au, mbaya zaidi, hufanikiwa dhidi ya mpaka usiofaa wa uaminifu.

Kuwasilisha kuki bila kuacha nakala

Uwasilishaji salama zaidi wa kimtambo kwenye Linux ni ingizo la kawaida. --cookie-on-stdin husoma thamani kutoka stdin, kwa hiyo kuki haionekani kamwe katika orodha ya hoja za mchakato, ambapo mtumiaji yeyote wa ndani anaweza kuisona kwa ps. Bomba linalothibitisha katika mchakato mmoja na kulisha handaki katika mwingine hushikilia thamani kwenye bomba badala ya faili au kigezo cha mazingira.

Hoja na vibadala vya mazingira ni dhaifu kwa sababu tofauti. Hoja inaonekana kwenye jedwali la michakato katika maisha yote ya mteja na mara nyingi huishia kwenye historia ya shell. Kigezo cha mazingira hurithiwa na michakato ya watoto, na kitengo cha systemd kinachokiweka kwenye faili ya kitengo huhifadhi siri katika usanidi unaosomeka. Ikiwa faili ni lazima, iweke kwa akaunti ya huduma na uifute kipindi kinapoisha.

Pia weka mpaka wa upendeleo kwa makusudi. Mchakato unaozungumza na mtoa utambulisho na labda kufungua kivinjari unapaswa kuendeshwa kama mtumiaji anayemiliki kuingia huko. Mchakato unaosanidi njia, DNS na kifaa cha handaki unaweza kuhitaji upendeleo zaidi. Kuendesha kivinjari kizima kama root ili kuki yake ipatikane kwa handaki linalomilikiwa na root ni mabadilishano mabaya, na usanidi wa kisasa wa OpenConnect unaweza kuwasilisha thamani kupita mpaka huo kwa uwazi.

Uwekaji kumbukumbu nao unastahili shaka hiyo hiyo. Matokeo ya kina ya mteja, script za msaada na uchunguzi wa lango vyote vinaweza kurudia nyenzo za ombi, na sio kila kiwango cha kumbukumbu huficha kuki. Nasa rekodi ndogo zaidi ya hitilafu unayohitaji, iweke nje ya njia za pamoja, na ukague sampuli iliyofichwa kabla ya kuiambatanisha na tikiti.

Uthibitishaji na kuisha katika awamu ya pili

Awamu ya pili bado inapaswa kuthibitisha seva. FINGERPRINT ambayo --authenticate huchapisha ni pini ya cheti katika umbo pin-sha256:, na kuiwasilisha kwa wito wa handaki kwa --servercert huweka ukaguzi umefungwa kwenye lango ulilothibitisha dhidi yake. Kuzima ukaguzi wa vyeti ili kurahisisha script huondoa uthibitisho pekee kwamba kuki inawasilishwa kwa mwenyeji unaokusudiwa.

Lango linapokataa kuki, suluhisho ni raundi mpya ya uthibitishaji, sio akiba ndefu. Hifadhi kuki kwa muda wa muunganisho tu, futa faili za muda unapotoka, na tumia mchakato wa kuondoa kipindi wa mtoa utambulisho au lango kipindi kinapofichuliwa au kifaa kinapopotea. Kuki iliyohifadhiwa kwenye akiba sio msamaha wa MFA.

Kabla ya kuendesha hii kiotomatiki, thibitisha mambo manne: handaki linaendeshwa chini ya akaunti sahihi, kuki inafika kupitia stdin, alama ya kidole ya cheti imepiniwa, na kipindi hutupwa handaki linapofungwa. Ikiwa kimoja hakipo, uendeshaji kiotomatiki umepanua uaminifu kwa kuki badala ya kuzalisha upya mtiririko wa mkono.