Perlukah menumpuk dua lapisan VPN? Tiga syarat untuk diperiksa
Dua lapisan VPN hanya membantu jika berakhir di host berbeda dan memakai kunci yang independen. Tiga syarat menentukan apakah penumpukan menambah keamanan atau hanya biaya CPU.
Sebelum menambahkan lapisan enkripsi kedua ke VPN, jawab satu pertanyaan dengan jujur: apa yang masih dipegang pengamat setelah kedua lapisan menyelesaikan tugasnya? Jika jawabannya adalah ciphertext dalam, tanpa perubahan, maka penumpukan hanya membeli waktu dan tidak lebih. Yang berikutnya adalah prosedur keputusan, bukan rekomendasi. Diagram yang sama menjadi CPU terbuang di satu penerapan dan jawaban tepat di penerapan lain, dan hanya tiga syarat yang memisahkan keduanya.
Catat apa yang disimpan pengamat
Catat objek yang dapat disimpan penyerang hari ini, lalu urutan penghapusan yang akhirnya akan menyingkap teks jelas. Terowongan luar menghasilkan ciphertext; ketika perlindungannya berakhir, yang tersisa adalah ciphertext terowongan dalam, masih tersegel. Melepas pembungkus bukanlah dekripsi. Kalimat itu menggambarkan penumpukan, dan hanya berlaku selama kunci dalam bertahan. Begitu kedua lapisan berbagi apa pun, garis waktu runtuh menjadi satu peristiwa.
Jadi artefak yang berguna adalah garis waktu, bukan diagram kotak. Untuk setiap lapisan, tulis titik akhir, pemilik kunci, pemeriksaan identitas, dan tahun ketika asumsi diperkirakan gagal.
Cara praktis menguji klaim Anda sendiri: anggap pengamat merekam semuanya dan tidak pernah menyerah. Di bawah asumsi itu, apakah rancangan masih melindungi muatan selama masa hidup yang diperlukan? Jika jawabannya bergantung pada pengamat memilih untuk tidak menyimpan lalu lintas, rancangan itu tidak punya jawaban.
Syarat satu: apakah lapisan berhenti di tempat berbeda?
Penumpukan membayar ketika kedua lapisan berakhir di domain kepercayaan berbeda, misalnya gateway IPsec yang dikelola penyedia di depan terowongan tingkat aplikasi yang berakhir di dalam jaringan Anda sendiri. Melepas lapisan luar lalu menghasilkan ciphertext yang hanya dapat dibuka host Anda, dan penyedia tidak pernah melihat teks jelas pada titik mana pun. Taruh kedua lapisan di gateway yang sama dan sifat itu hilang. Siapa pun yang membobol kotak itu membaca lalu lintas antara dua operasi dekripsi, berapa pun pembungkus yang ditunjukkan diagram.
Periksa itu dengan keadaan terpasang, bukan dengan rancangan. Di Linux, ip xfrm state mendaftar setiap asosiasi keamanan dan titik akhirnya, yang menentukan di mana setiap lapisan benar-benar berhenti.
Syarat dua: apakah materi kunci benar-benar independen?
Dua lapisan yang dibangun dari satu sertifikat, satu kunci yang dibagi sebelumnya, atau satu pustaka vendor adalah satu lapisan dengan langkah tambahan. Kebocoran satu kredensial lalu membuka keduanya, dan satu bug implementasi menghapus keduanya sekaligus. Independensi harus terlihat dalam konfigurasi, bukan diklaim di slide.
Di sinilah penetapan kunci hibrida mengalahkan penumpukan terowongan. IKEv2 dapat membawa beberapa pertukaran kunci dalam satu negosiasi, sehingga grup klasik dan KEM pascakuantum keduanya dapat memberi makan kunci sesi yang sama alih-alih dibungkus satu sama lain. Hasilnya adalah satu asosiasi keamanan yang kuncinya bergantung pada kedua rahasia, dan penyerang harus memecahkan keduanya. Itu konstruksi terdokumentasi dengan komposisi yang ditetapkan, yang bukan merupakan tumpukan buatan sendiri dari dua produk VPN. Di strongSwan, swanctl --list-sas mencetak proposal yang dinegosiasikan untuk setiap SA, dan begitulah Anda memastikan apa yang benar-benar berjalan, bukan apa yang Anda konfigurasikan.
Syarat tiga: apakah data hidup lebih lama dari asumsi luar?
Lapisan yang harus bertahan dua puluh tahun memerlukan argumen dua puluh tahun. Merekam sekarang dan mendekripsi nanti itu murah, dan itulah sebabnya lapisan luar klasik tidak dapat diperlakukan sebagai pembungkus sementara di sekitar sesuatu yang lebih kuat.
Tanyakan kapan setiap kunci menjadi dapat dipulihkan, bukan apakah sandi sudah dipecahkan hari ini. Pertukaran kunci statis tanpa kerahasiaan maju gagal secara retrospektif pada hari kunci privat jatuh. Kesepakatan kunci efemeral hanya gagal untuk sesi yang dapat diserang penyerang saat masih hidup, atau ketika algoritme itu sendiri melemah. Perbedaan itu menentukan apakah lapisan dalam masih membantu pada 2040. Itu juga menentukan apakah lapisan luar mengubah apa pun, karena lapisan luar dengan masa hidup kunci yang lebih lemah hanya menjadi titik paling awal pada garis waktu.
Apa yang dibangun sebagai gantinya ketika jawabannya tidak
Jika salah satu dari tiga syarat gagal, buang penumpukan dan belanjakan upaya pada lapisan yang benar-benar membawa persyaratan masa hidup. Konfigurasikan pertukaran kunci hibrida dalam protokol yang sudah Anda jalankan, jaga implementasi tetap mutakhir, dan tuliskan komposisi yang Anda andalkan. Menyebut ML-KEM dalam dokumen rancangan bukan properti keamanan, dan FIPS 203 mendefinisikan mekanisme enkapsulasi kunci, bukan terowongan Anda.
Di mana lapisan kedua benar-benar memperoleh tempatnya, gambarkan sebagai pertahanan berlapis, bukan sebagai bukti. Lalu verifikasi komposisinya: titik akhir mana memegang kunci mana, identitas apa yang diperiksa setiap sisi, dan apa yang dapat dibaca operator dengan akses konsol. Rancangan yang lolos tiga pertanyaan itu layak mendapat CPU tambahan. Yang tidak lolos hanyalah diagram.
Sebelum jendela perubahan, tangkap tabel SA saat ini dan proposal yang dinegosiasikan, lalu tangkap lagi setelahnya dan bandingkan, karena satu-satunya bukti yang penting adalah apa yang benar-benar disetujui perangkat.