Mengapa AES-256 Tidak Menjelaskan Suite Enkripsi VPN

Tanyakan enkripsi apa yang dipakai VPN dan jawabannya biasanya datang sebagai satu kata: AES-256, atau ChaCha20, atau mungkin WireGuard. Jawaban itu menyebut satu komponen dari satu lapisan, sedangkan yang benar-benar melindungi koneksi adalah sekumpulan algoritme yang mengisi empat peran berbeda. Mencampur komponen dengan susunannya adalah kesalahan paling umum dalam percakapan ini, dan itu menghasilkan perbandingan yang tidak bisa diselesaikan.

Empat pekerjaan dalam satu koneksi

Enkripsi massal mengubah teks biasa menjadi teks tersandi untuk kanal data, dan kuncinya diturunkan bukan dikirim. Perlindungan integritas mendeteksi perubahan, yang merupakan pekerjaan terpisah meski satu konstruksi melakukan keduanya. Penetapan kunci menghasilkan materi lalu lintas bersama, dan autentikasi peer memutuskan siapa yang ada di ujung lain. Jika salah satunya hilang, koneksi tidak aman, sekuat apa pun bagian yang tersisa.

Sejumlah rancangan menggabungkan dua peran menjadi satu. AES-GCM dan ChaCha20-Poly1305 adalah konstruksi enkripsi terautentikasi, jadi kerahasiaan dan integritas datang bersama; AES-CBC tidak, dan memerlukan kode autentikasi pesan terpisah dengan kuncinya sendiri. Karena itu membaca proposal sebagai kantung angka independen salah membaca yang dirancang sebagai pasangan.

Peran-peran itu juga berada di lapisan berbeda, karena itu kata yang sama bisa berarti lain pada dua produk. Cipher blok di dalam ESP dan cipher blok di dalam TLS adalah primitif yang sama dalam negosiasi berbeda dengan persyaratan berbeda. Karena itu mengutip primitif tanpa mode dan lapisannya bisa lebih buruk daripada tidak mengutip apa pun.

Mengapa nama cipher hampir tidak mengatakan apa pun

Ambil frasa AES-256 dengan serius sejenak: itu menunjuk cipher blok dan ukuran kunci. Itu tidak mengatakan apa pun tentang mode operasi, apakah integritas disediakan, bagaimana kunci ditetapkan atau bagaimana peer diautentikasi. Dua produk bisa sama-sama mengiklankan AES-256 dan berbeda dalam segala hal lain, termasuk satu yang memasangkannya dengan mode tak terautentikasi dan satu lagi yang memakai mode AEAD dengan pertukaran kunci modern.

TLS 1.3 membawa pemisahan ini ke dalam standar, yang merupakan koreksi berguna bagi siapa pun yang mempelajari kosakata lama. Suite cipher-nya hanya menyebut AEAD dan hash, sedangkan grup pertukaran kunci dan algoritme tanda tangan dinegosiasikan sebagai parameter terpisah. Karena itu nama suite TLS 1.3 tidak sebanding dengan nama suite TLS 1.2, meski keduanya muncul di bidang yang sama pada berkas konfigurasi. Auditor yang membandingkan kedua string secara langsung menarik kesimpulan yang tidak didukung protokol. Baca juga grup yang dinegosiasikan dan parameter tanda tangan, atau perbandingannya tidak lengkap.

WireGuard memilih jalan sebaliknya dan menghapus negosiasi hampir seluruhnya: protokol menetapkan kumpulan algoritme tetap, jadi dua implementasi bekerja sama atau tidak. Itu pilihan desain yang sah, dan itu juga berarti pertanyaan suite apa yang dinegosiasikan WireGuard tidak punya jawaban yang layak dibandingkan. Jika Anda mengauditnya, baca spesifikasinya sekali lalu audit penanganan kunci di sekitarnya alih-alih negosiasinya.

Lapisan menentukan kosakata

Penerapan IPsec bernegosiasi dua kali: proposal IKE untuk kanal kendali dan transformasi ESP untuk data, dan keduanya bisa berbeda secara sah. Membaca yang pertama lalu menganggapnya menjelaskan yang kedua adalah sumber kebingungan umum saat audit, karena berkas konfigurasi menyebut keduanya dan yang menarik adalah yang kedua.

Nama yang tersedia di satu pustaka tidak otomatis diterapkan untuk jalur data lain. Karena itu pernyataan bahwa produk kami mendukung AES-256 lebih lemah daripada kedengarannya, dan karena itu masalah interoperabilitas biasanya dipecahkan dengan menemukan irisan yang terpelihara alih-alih mengaktifkan setiap algoritme lama di kedua sisi.

Spesifikasi TLS 1.3 adalah contoh terbit paling jelas dari pemisahan itu, karena mendefinisikan suite sebagai pasangan dan memindahkan sisanya ke negosiasinya sendiri. Setelah bentuk itu dikenal, proposal IPsec dan satu kumpulan tetap WireGuard terbaca sebagai variasi dari gagasan yang sama.

Baca hasil negosiasi, lalu berhenti

Proposal yang dikonfigurasi bukan bukti apa yang dipilih dua peer. Sesi hidup membawa jawabannya, dan setiap implementasi arus utama dapat melaporkannya tanpa menangkap paket.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Pada keluaran, baca algoritme yang dipilih bukan daftar yang ditawarkan. Jika jawabannya lebih lemah daripada yang dimaksud kebijakan, perbaikan ada pada konfigurasi proposal di salah satu sisi, dan ketidaksesuaian pada implementasi modern biasanya tampak sebagai negosiasi gagal bukan penurunan diam-diam.

Lalu ingat apa yang tidak dicakup suite. Rute, izin aplikasi, pencatatan, dan penyimpanan adalah keputusan terpisah dengan tinjauannya sendiri, dan susunan kriptografis yang kompatibel tidak mengatakan apa pun tentangnya. Diskusi tentang cipher layak dilakukan, tetapi menjawab pertanyaan yang lebih sempit daripada yang sebenarnya diajukan kebanyakan orang.

Pertahankan kosakata yang tepat dan argumennya menjadi lebih pendek. Suite adalah kumpulan peran pada satu lapisan, cipher adalah satu komponen, dan hasil negosiasi adalah satu-satunya yang menjelaskan koneksi yang benar-benar Anda miliki. Segala hal lain dalam perbandingan hanyalah hiasan.