Paano ginagawang tunnel ng OpenConnect ang cookie sa pag-login?

Pinag-uugnay ng OpenConnect ang dalawang hiwalay na palitan sa isang panandaliang halaga: ang web login at ang VPN tunnel. Ang unang palitan ay ordinaryong HTTPS: ang mga kredensyal, isang SAML na biyahe o token ay pumupunta sa gateway, at ang sagot ay may dalang cookie ng pagpapatunay. Ipinapakita ng ikalawang palitan ang cookie na iyon sa parehong gateway bilang patunay na nangyari na ang web phase, at doon lang tumataas ang tunnel.

Sa panahon ng pag-login walang napag-uusapan tungkol sa tunnel. Ito ang bahaging dapat maintindihan, dahil inaakala ng karamihan ng error sa script na ang cookie ay password na dapat itago, o susi na nagpoprotekta sa trapiko, samantalang ito ay tiket na tagapagdala para sa isang partikular na session ng gateway.

Ano ang ipinagpapalit ng kliyente at gateway, sa pagkakasunod

Ang yugto ng pagpapatunay ay mukhang ordinaryong protektadong website. Nagpapadala ang OpenConnect ng kredensyal ng gumagamit, o sinusundan ang pag-redirect ng gateway patungo sa tagapagbigay ng pagkakakilanlan, at sumasagot ang gateway ng dokumentong naglalaman ng cookie ng pagpapatunay. Sa protocol na AnyConnect ang halagang iyon ay naglalakbay sa header ng cookie sa mga susunod na kahilingan, karaniwang sa pangalang tulad ng webvpn, at itinuturing ito ng manwal bilang kredensyal na nagdadala ng session pasulong.

Ang ikalawang yugto ay kahilingang CONNECT sa VPN endpoint ng gateway na may kalakip na cookie. Sinusuri ito ng gateway, naglalaan ng address, at sinisimulan ng kliyente ang CSTP sa ibabaw ng TLS, at ang DTLS ay opsyonal na mas mabilis na daanan ng datos kapag umiiral na ang session. Sa puntong ito lang naitatakda ang mga parameter ng tunnel, ruta, setting ng DNS at mga susi ng trapiko ng session. Dinala ng cookie ang kliyente sa pinto; wala itong na-encrypt.

Ipinapaliwanag ng pagkakasunod na ito kung bakit may openconnect --authenticate. Patakbuhin ito, at ginagawa nito ang web phase, nagpi-print ng maliit na bloke ng mga shell variable tulad ng COOKIE, HOST, CONNECT_URL at FINGERPRINT, at pagkatapos ay lumalabas bago pa man buuin ang anumang tunnel. Maaaring simulan ng isang wrapper script ang tunay na koneksyon gamit ang mga halagang iyon, at iyon mismo ang paghahati na kailangan ng deployment na walang screen o may dalawang container.

Ang cookie ay tagapagdala ng session, hindi susi

Ituring ang halaga gaya ng pagturing mo sa session ID sa isang web application. Sinumang may hawak nito sa buong buhay nito ay maaaring humiling sa gateway ng tunnel na nararapat sa session na iyon, kaya mahalaga ang pagiging lihim nito. Ngunit ang pagkopya nito ay hindi nagbubunyag ng trapiko, dahil ang pagiging kompidensyal ng tunnel ay nagmumula sa TLS handshake at sa mga nagawang susi, hindi sa string ng cookie.

Hindi rin ito permanenteng pahintulot. Ang gateway at ang tagapagbigay ng pagkakakilanlan ang nagpapasya kung gaano katagal nabubuhay ang session, at ang browser na nagpapakita pa rin ng naka-login na pahina ay walang sinasabi tungkol sa kung may bisa pa ang session ng tunnel. Ang muling pagkonekta pagkatapos ng pag-expire ay nangangahulugang ulitin ang web phase at gumawa ng bagong cookie, at iyon ang layunin ng muling pagpapatunay, hindi hadlang na dapat iwasan sa pamamagitan ng inhinyeriya.

Huwag ituring ang cookie na pangkalahatang kapalit ng iba pang kredensyal. Ang SAML assertion, password ng browser at cookie na inilabas ng ibang serbisyo ay magkakaibang bagay na may magkakaibang audience, at ang pagdikit ng isa sa field ng iba ay karaniwang nabibigo sa gateway o, mas malala, nagtatagumpay laban sa maling hangganan ng tiwala.

Paghahatid ng cookie nang walang naiiwang kopya

Ang pinakaligtas na mekanikal na paghahatid sa Linux ay standard input. Binabasa ng --cookie-on-stdin ang halaga mula sa stdin, kaya hindi kailanman lumilitaw ang cookie sa listahan ng argumento ng proseso, kung saan mababasa ito ng kahit sinong lokal na gumagamit gamit ang ps. Ang pipeline na nagpapatunay sa isang proseso at nagpapakain sa tunnel sa iba ay nagtatago ng halaga sa tubo sa halip na sa file o environment variable.

Ang mga argumento at environment variable ay mas mahina sa magkakaibang dahilan. Ang argumento ay nakikita sa talahanayan ng proseso sa buong buhay ng kliyente at madalas nauuwi sa history ng shell. Ang environment variable ay namamana ng mga anak na proseso, at ang systemd unit na nagtatakda nito sa unit file ay nag-iimbak ng lihim sa nababasang configuration. Kung kailangan talaga ng file, limitahan ito sa service account at tanggalin kapag natapos ang session.

Panatilihin ding sinasadya ang hangganan ng pribilehiyo. Ang prosesong nakikipag-usap sa tagapagbigay ng pagkakakilanlan at maaaring magbukas ng browser ay dapat tumakbo bilang gumagamit na nagmamay-ari ng login na iyon. Ang prosesong nagko-configure ng ruta, DNS at aparato ng tunnel ay maaaring mangailangan ng mas maraming pribilehiyo. Ang pagpapatakbo ng buong browser bilang root para maging available ang cookie nito sa tunnel na pag-aari ng root ay maling palitan, at ang mga modernong setup ng OpenConnect ay maaaring tahasang maghatid ng halaga sa kabila ng hangganang iyon.

Ang pag-log ay karapat-dapat sa parehong pagdududa. Ang detalyadong output ng kliyente, mga helper script at diagnostiko ng gateway ay maaaring umulit ng materyal ng kahilingan, at hindi lahat ng antas ng log ay nagtatakip ng cookie. Kunin ang pinakamaliit na talaan ng error na kailangan mo, ilayo ito sa pinagsasaluhang channel, at suriin ang tinakpang sample bago ito ilakip sa isang ticket.

Pagpapatunay at pag-expire sa ikalawang yugto

Kailangan pa ring patunayan ng ikalawang yugto ang server. Ang FINGERPRINT na ipinipi-print ng --authenticate ay pin ng sertipiko sa anyong pin-sha256:, at ang paghahatid nito sa tawag ng tunnel gamit ang --servercert ay nagpapanatili ng pagsusuring nakaangkla sa gateway na pinagpatunayan mo. Ang pagpatay sa pagsusuri ng sertipiko para gawing simple ang script ay nag-aalis ng nag-iisang patunay na ang cookie ay inihahatid sa nilalayong host.

Kapag tinanggihan ng gateway ang cookie, ang solusyon ay bagong ikot ng pagpapatunay, hindi mas mahabang cache. Itago ang cookie habang buhay lang ng koneksyon, burahin ang mga pansamantalang file sa paglabas, at gamitin ang proseso ng pag-alis ng session ng tagapagbigay ng pagkakakilanlan o ng gateway kapag nalantad ang session o nawala ang aparato. Ang naka-cache na cookie ay hindi pagbubukod sa MFA.

Bago gawing awtomatiko ito, patunayan ang apat na bagay: tumatakbo ang tunnel sa tamang account, dumarating ang cookie sa pamamagitan ng stdin, naka-pin ang fingerprint ng sertipiko, at itinatapon ang session kapag nagsara ang tunnel. Kung may kulang, pinalawak ng automation ang tiwala sa cookie sa halip na muling ginawa ang manu-manong daloy.