Bagaimana OpenConnect mengubah cookie login menjadi terowongan?

OpenConnect menyatukan dua pertukaran terpisah dengan satu nilai berumur pendek: login web dan terowongan VPN. Pertukaran pertama adalah HTTPS biasa: kredensial, perjalanan SAML, atau token menuju gateway, dan balasannya membawa cookie autentikasi. Pertukaran kedua menyodorkan cookie itu ke gateway yang sama sebagai bukti bahwa fase web sudah terjadi, dan barulah terowongan naik.

Selama login tidak ada yang dinegosiasikan soal terowongan. Itulah bagian yang layak dipahami, karena sebagian besar kesalahan skrip menganggap cookie adalah kata sandi yang harus disimpan, atau kunci yang melindungi lalu lintas, padahal sebenarnya itu tiket pembawa untuk sesi gateway tertentu.

Apa yang dipertukarkan klien dan gateway, secara berurutan

Fase autentikasi tampak seperti situs web terlindungi biasa. OpenConnect mengirim kredensial pengguna, atau mengikuti pengalihan gateway ke penyedia identitas, dan gateway membalas dengan dokumen yang menyematkan cookie autentikasi. Dalam protokol AnyConnect nilai itu berjalan di header cookie pada permintaan berikutnya, biasanya dengan nama seperti webvpn, dan manual memperlakukannya sebagai kredensial yang membawa sesi maju.

Fase kedua adalah permintaan CONNECT ke titik akhir VPN gateway dengan cookie itu terlampir. Gateway memeriksanya, memberikan alamat, dan klien memulai CSTP di atas TLS, dengan DTLS sebagai jalur data opsional yang lebih cepat begitu sesi ada. Hanya pada titik ini parameter terowongan, rute, pengaturan DNS, dan kunci lalu lintas sesi ditetapkan. Cookie mengantar klien melewati pintu; ia tidak mengenkripsi apa pun.

Urutan inilah yang menjelaskan mengapa openconnect --authenticate ada. Jalankan, dan ia melakukan fase web, mencetak blok kecil variabel shell seperti COOKIE, HOST, CONNECT_URL, dan FINGERPRINT, lalu keluar sebelum terowongan apa pun dibangun. Skrip pembungkus kemudian dapat memulai koneksi sebenarnya dengan nilai-nilai itu, dan itulah tepatnya pemisahan yang dibutuhkan penerapan tanpa layar atau dua kontainer.

Cookie adalah pembawa sesi, bukan kunci

Perlakukan nilai itu seperti Anda memperlakukan ID sesi di aplikasi web. Siapa pun yang memegangnya selama masa hidupnya dapat meminta gateway terowongan yang menjadi hak sesi itu, jadi kerahasiaannya penting. Tetapi menyalinnya tidak mengungkap lalu lintas, karena kerahasiaan terowongan berasal dari jabat tangan TLS dan kunci turunan, bukan dari untai cookie.

Cookie juga bukan pemberian permanen. Gateway dan penyedia identitas menentukan berapa lama sesi hidup, dan peramban yang masih menampilkan halaman masuk tidak mengatakan apa pun tentang apakah sesi terowongan masih sah. Menyambung ulang setelah kedaluwarsa berarti mengulang fase web dan menghasilkan cookie baru, dan itulah maksud autentikasi ulang, bukan gangguan yang harus diakali dengan rekayasa.

Jangan memperlakukan cookie sebagai pengganti universal kredensial lain. Asersi SAML, kata sandi peramban, dan cookie yang diterbitkan layanan lain adalah objek berbeda dengan audiens berbeda, dan menempelkan yang satu ke kolom yang lain biasanya gagal di gateway atau, lebih buruk, berhasil terhadap batas kepercayaan yang salah.

Menyerahkan cookie tanpa meninggalkan salinan

Penyerahan mekanis paling aman di Linux adalah masukan standar. --cookie-on-stdin membaca nilai dari stdin, sehingga cookie tidak pernah muncul di daftar argumen proses, tempat pengguna lokal mana pun dapat membacanya dengan ps. Saluran pipa yang mengautentikasi di satu proses dan memberi makan terowongan di proses lain menyimpan nilai di pipa, bukan di berkas atau variabel lingkungan.

Argumen dan variabel lingkungan lebih lemah karena alasan berbeda. Argumen terlihat di tabel proses sepanjang masa hidup klien dan sering berakhir di riwayat shell. Variabel lingkungan diwariskan ke proses anak, dan unit systemd yang menyetelnya di berkas unit menyimpan rahasia dalam konfigurasi yang dapat dibaca. Jika berkas memang diperlukan, batasi ke akun layanan dan hapus saat sesi berakhir.

Jaga juga batas hak istimewa secara sengaja. Proses yang berbicara dengan penyedia identitas dan mungkin membuka peramban sebaiknya berjalan sebagai pengguna pemilik login itu. Proses yang mengonfigurasi rute, DNS, dan perangkat terowongan mungkin memerlukan hak istimewa lebih. Menjalankan seluruh peramban sebagai root agar cookienya tersedia bagi terowongan milik root adalah pertukaran yang salah, dan penyiapan OpenConnect modern dapat menyerahkan nilai itu melintasi batas tersebut secara eksplisit.

Pencatatan log pun pantas dicurigai. Keluaran klien yang bertele-tele, skrip pembantu, dan diagnostik gateway semuanya dapat mengulang bahan permintaan, dan tidak setiap tingkat log menyamarkan cookie. Tangkap catatan galat terkecil yang Anda butuhkan, jauhkan dari saluran bersama, dan periksa contoh yang disamarkan sebelum melampirkannya ke tiket.

Verifikasi dan kedaluwarsa pada fase kedua

Fase kedua tetap harus memverifikasi server. FINGERPRINT yang dicetak --authenticate adalah pin sertifikat dalam bentuk pin-sha256:, dan menyerahkannya ke pemanggilan terowongan dengan --servercert menjaga pemeriksaan tetap berjangkar pada gateway yang Anda autentikasi. Mematikan pemeriksaan sertifikat agar skrip lebih sederhana menghapus satu-satunya bukti bahwa cookie diserahkan kepada host yang dimaksud.

Ketika gateway menolak cookie, solusinya adalah putaran autentikasi baru, bukan cache yang lebih panjang. Simpan cookie hanya selama masa hidup koneksi, hapus berkas sementara saat keluar, dan gunakan proses penghapusan sesi penyedia identitas atau gateway ketika sesi terekspos atau perangkat hilang. Cookie yang di-cache bukan pengecualian dari MFA.

Sebelum mengotomatiskan ini, verifikasi empat hal: terowongan berjalan dengan akun yang benar, cookie tiba lewat stdin, sidik jari sertifikat dipin, dan sesi dibuang saat terowongan ditutup. Jika ada yang hilang, otomatisasi telah memperluas kepercayaan pada cookie alih-alih mereproduksi alur manual.