Bagaimana OpenConnect menukar kuki log masuk menjadi terowong?

OpenConnect mengikat dua pertukaran berasingan dengan satu nilai jangka pendek: log masuk web dan terowong VPN. Pertukaran pertama ialah HTTPS biasa: kelayakan, perjalanan SAML atau token pergi ke gerbang, dan balasannya membawa kuki pengesahan. Pertukaran kedua mengemukakan kuki itu kepada gerbang yang sama sebagai bukti fasa web sudah berlaku, dan barulah terowong naik.

Semasa log masuk tiada apa tentang terowong dirundingkan. Inilah bahagian yang wajar difahami, kerana kebanyakan kesilapan skrip menganggap kuki itu kata laluan untuk disimpan, atau kunci yang melindungi trafik, sedangkan ia sebenarnya tiket pembawa untuk sesi gerbang tertentu.

Apa yang ditukar klien dan gerbang, mengikut urutan

Fasa pengesahan kelihatan seperti laman web terlindung biasa. OpenConnect menghantar kelayakan pengguna, atau mengikut ubah hala gerbang ke penyedia identiti, dan gerbang membalas dengan dokumen yang membenamkan kuki pengesahan. Dalam protokol AnyConnect nilai itu bergerak dalam pengepala kuki pada permintaan berikutnya, biasanya dengan nama seperti webvpn, dan manual menganggapnya sebagai kelayakan yang membawa sesi ke hadapan.

Fasa kedua ialah permintaan CONNECT ke titik akhir VPN gerbang dengan kuki itu dilampirkan. Gerbang menyemaknya, memberikan alamat, dan klien memulakan CSTP di atas TLS, dengan DTLS sebagai laluan data pilihan yang lebih pantas apabila sesi wujud. Hanya pada titik ini parameter terowong, laluan, tetapan DNS dan kunci trafik sesi ditetapkan. Kuki itu membawa klien melepasi pintu; ia tidak menyulitkan apa-apa.

Urutan inilah yang menjelaskan mengapa openconnect --authenticate wujud. Jalankannya dan ia melakukan fasa web, mencetak blok kecil pemboleh ubah shell seperti COOKIE, HOST, CONNECT_URL dan FINGERPRINT, kemudian keluar sebelum mana-mana terowong dibina. Skrip pembalut kemudian boleh memulakan sambungan sebenar dengan nilai itu, dan itulah tepatnya pemisahan yang diperlukan oleh penggunaan tanpa skrin atau dua bekas.

Kuki ialah pembawa sesi, bukan kunci

Layan nilai itu seperti anda melayan ID sesi dalam aplikasi web. Sesiapa yang memegangnya sepanjang hayatnya boleh meminta gerbang terowong yang layak untuk sesi itu, jadi kerahsiaannya penting. Tetapi menyalinnya tidak mendedahkan trafik, kerana kerahsiaan terowong datang daripada jabat tangan TLS dan kunci terbitan, bukan daripada rentetan kuki.

Ia juga bukan kebenaran kekal. Gerbang dan penyedia identiti menentukan berapa lama sesi hidup, dan pelayar yang masih memaparkan halaman log masuk tidak mengatakan apa-apa tentang sama ada sesi terowong masih sah. Menyambung semula selepas tamat tempoh bermakna mengulang fasa web dan menghasilkan kuki baharu, dan itulah maksud pengesahan semula, bukan kerenah yang perlu diakali dengan kejuruteraan.

Jangan anggap kuki sebagai pengganti sejagat untuk kelayakan lain. Pernyataan SAML, kata laluan pelayar dan kuki yang dikeluarkan oleh perkhidmatan lain ialah objek berbeza dengan khalayak berbeza, dan menampal satu ke dalam medan yang lain biasanya gagal di gerbang atau, lebih buruk, berjaya terhadap sempadan kepercayaan yang salah.

Menyerahkan kuki tanpa meninggalkan salinan

Penyerahan mekanikal paling selamat di Linux ialah input standard. --cookie-on-stdin membaca nilai daripada stdin, jadi kuki tidak pernah muncul dalam senarai argumen proses, tempat mana-mana pengguna setempat boleh membacanya dengan ps. Saluran paip yang mengesahkan dalam satu proses dan menyuap terowong dalam proses lain menyimpan nilai dalam paip, bukan dalam fail atau pemboleh ubah persekitaran.

Argumen dan pemboleh ubah persekitaran lebih lemah atas sebab berbeza. Argumen kelihatan dalam jadual proses sepanjang hayat klien dan sering berakhir dalam sejarah shell. Pemboleh ubah persekitaran diwarisi oleh proses anak, dan unit systemd yang menetapkannya dalam fail unit menyimpan rahsia dalam konfigurasi yang boleh dibaca. Jika fail benar-benar perlu, hadkannya kepada akaun perkhidmatan dan hapuskannya apabila sesi tamat.

Jaga juga sempadan keistimewaan secara sengaja. Proses yang bercakap dengan penyedia identiti dan mungkin membuka pelayar sepatutnya berjalan sebagai pengguna pemilik log masuk itu. Proses yang mengkonfigurasi laluan, DNS dan peranti terowong mungkin memerlukan lebih keistimewaan. Menjalankan seluruh pelayar sebagai root supaya kukinya tersedia untuk terowong milik root ialah pertukaran yang salah, dan persediaan OpenConnect moden boleh menyerahkan nilai itu merentasi sempadan tersebut secara jelas.

Pencatatan log juga wajar disyaki. Output klien terperinci, skrip pembantu dan diagnostik gerbang semuanya boleh mengulang bahan permintaan, dan bukan setiap tahap log menyamarkan kuki. Tangkap rekod ralat terkecil yang anda perlukan, jauhkan daripada saluran bersama, dan semak sampel yang disamarkan sebelum melampirkannya pada tiket.

Pengesahan dan tamat tempoh dalam fasa kedua

Fasa kedua masih perlu mengesahkan pelayan. FINGERPRINT yang dicetak oleh --authenticate ialah pin sijil dalam bentuk pin-sha256:, dan menyerahkannya kepada panggilan terowong dengan --servercert mengekalkan pemeriksaan berlabuh pada gerbang yang anda sahkan. Mematikan pemeriksaan sijil untuk memudahkan skrip menghapuskan satu-satunya bukti bahawa kuki diserahkan kepada hos yang dimaksudkan.

Apabila gerbang menolak kuki, penyelesaiannya ialah pusingan pengesahan baharu, bukan cache yang lebih panjang. Simpan kuki hanya sepanjang hayat sambungan, hapuskan fail sementara semasa keluar, dan gunakan proses pembuangan sesi penyedia identiti atau gerbang apabila sesi terdedah atau peranti hilang. Kuki yang dicache bukan pengecualian daripada MFA.

Sebelum mengautomasikan ini, sahkan empat perkara: terowong berjalan dengan akaun yang betul, kuki tiba melalui stdin, cap jari sijil dipin, dan sesi dibuang apabila terowong ditutup. Jika ada yang hilang, automasi telah meluaskan kepercayaan pada kuki dan bukan menghasilkan semula aliran manual.