VPN TLS versus IPsec: lima bidang yang layak ditinjau
Bandingkan VPN TLS dan VPN IPsec menurut rilis, versi protokol, suite, identitas peer, dan cakupan yang terbuka, serta hasil kegagalan yang benar-benar Anda konfigurasikan.
Memeringkatkan VPN TLS terhadap VPN IPsec menurut keluarga protokol menjawab pertanyaan yang tidak diajukan siapa pun, dan biasanya mengutip konstruksi yang sudah ditinggalkan kedua keluarga bertahun-tahun lalu. Yang benar-benar dapat dinilai seorang peninjau adalah perlindungan yang dinegosiasikan, identitas peer, model klien, dan layanan yang terbuka. Keempat hal itu terlihat dalam penerapan, dan tidak satu pun mengikuti label produk. Mintalah lima bidang dan percakapannya menjadi konkret.
Lima bidang, dan label bukan salah satunya
Bidang pertama adalah rilis perangkat lunak yang didukung, karena deskripsi protokol tanpa versi hanyalah brosur. Bidang kedua adalah versi protokol yang dinegosiasikan, yang menentukan konstruksi mana yang tersedia. Bidang ketiga adalah suite perlindungan, bidang keempat metode autentikasi untuk peer maupun pengguna, dan bidang kelima cakupan akses yang diberikan produk setelah penerimaan.
Label VPN SSL mencakup setidaknya tiga produk berbeda: klien jaringan penuh, proksi aplikasi, dan portal warisan berbasis peramban. Ketiganya membuka layanan berbeda dan gagal dengan cara berbeda, sehingga label tidak dapat menggantikan bidang cakupan.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
Apa yang sebenarnya diubah enkripsi terautentikasi
TLS 1.3 mewajibkan enkripsi terautentikasi, yang mengeluarkan konstruksi MAC-then-encrypt lama dari protokol alih-alih menjadikannya opsional. IPsec ESP sudah memiliki suite enkripsi terautentikasi selama itu juga, dengan AES-GCM didefinisikan dalam RFC tersendiri. Pada kedua keluarga jaminannya berasal dari suite yang dinegosiasikan, bukan dari nama keluarga, karena itu daftar bidang dimulai dengan versi. Peninjau yang tidak dapat menyebut suite tidak punya apa pun untuk dinilai.
Karena itu perbandingan historis menyesatkan. Penerapan yang dipatok pada versi TLS lama dengan suite CBC dan penerapan yang menjalankan TLS 1.3 dengan suite AEAD bukanlah postur keamanan yang sama, meskipun keduanya VPN TLS. Pemisahan yang sama ada di sisi IPsec antara suite ESP modern dan kombinasi warisan.
Bacalah nilai yang dinegosiasikan, bukan konfigurasi yang Anda maksudkan. Perintah di bawah menunjukkan apa yang sebenarnya disepakati endpoint yang berjalan dan terowongan yang berjalan.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas
Jika endpoint tidak mau menegosiasikan TLS 1.3, itu temuan, bukan preferensi. Jika terowongan mencantumkan suite yang tidak Anda duga, konfigurasi yang penting adalah yang dipilih para peer, bukan yang ada di templat.
Identitas peer adalah pertanyaan terpisah
Enkripsi tanpa peer terverifikasi melindungi lalu lintas dari pengamat dan menyerahkannya kepada siapa pun yang menjawab koneksi. Autentikasi peer menanyakan identitas apa yang diharapkan, materi kepercayaan apa yang memvalidasinya, dan bagaimana klien berperilaku ketika jawabannya tidak cocok. Rantai sertifikat, kunci yang dipasak, dan rahasia yang dibagikan sebelumnya adalah tiga jawaban berbeda dengan tiga biaya operasional berbeda.
Lalu ajukan pertanyaan yang sama tentang pengguna atau perangkat. Gateway yang mengautentikasi mesin dan menerima pengguna mana pun, atau sebaliknya, memiliki postur tertentu yang semestinya dituliskan, bukan diasumsikan. Izin sumber daya yang diterapkan setelah penerimaan adalah bagian dari bidang yang sama, karena autentikasi bukan otorisasi.
Mempertahankan pemeriksaan nama host dan sertifikat lebih penting daripada keakraban jendela masuk. Klien yang dikonfigurasi mengabaikan verifikasi telah menghapus satu-satunya langkah yang membedakan gateway Anda dari tiruan yang meyakinkan.
Batas yang dibuka produk
Portal tanpa klien memproksikan operasi aplikasi terpilih melalui gateway, sehingga pengguna mencapai antarmuka, bukan jaringan. Klien terowongan penuh membawa apa pun yang dipilih rute dan kebijakan penyaringannya, yang merupakan permukaan jauh lebih besar. Membandingkan keduanya menurut kekuatan protokol melewatkan perbedaan dalam apa yang dapat dicapai penyerang melaluinya. Satu membuka antarmuka aplikasi, yang lain jaringan teruting, dan keduanya menuntut tinjauan berbeda.
Tanyakan layanan apa yang terbuka, operasi apa yang diotorisasi, dan apa yang didengarkan gateway itu sendiri. Antarmuka manajemen yang dapat dijangkau dari alamat yang sama dengan portal pengguna adalah temuan penerapan, dan tidak ada pilihan protokol yang mengimbanginya.
Cakupan per aplikasi mempersempit permukaan lebih jauh, dan juga mengubah perilaku kegagalan saat terowongan putus. Rancangan yang mengasumsikan jangkauan terowongan penuh akan rusak dengan cara yang tidak dikenal rancangan per aplikasi, dan beban dukungan menyusul.
Putuskan hasil kegagalan dan siklus hidup
Apa yang terjadi ketika autentikasi atau perlindungan tidak tersedia adalah keputusan kebijakan yang termasuk dalam tinjauan. Hasil yang diblokir dan fallback langsung yang tidak diumumkan memiliki konsekuensi berbeda, dan perbedaannya tak terlihat dalam daftar fitur. Nyatakan perilaku yang dimaksudkan di samping sumber daya yang dilindunginya.
Sertakan siklus hidup tambalan dan dukungan gateway, fitur eksternalnya yang aktif, dan jalur pembaruan klien. Pilihan protokol yang benar tidak membuat layanan yang buruk penerapannya menjadi aman, dan sebagian besar insiden hidup di celah itu, bukan di suite.
Tuliskan lima bidang, kebijakan kegagalan, dan pemilik siklus hidup dalam satu halaman. Halaman itu adalah tinjauan; perbandingan keluarga protokol adalah opini.