OpenVPN EC vs ED: mengapa nama-nama ini bukan tangga kekuatan

Letakkan ec, ed, ecdh, ecdsa, auth dan daftar cipher TLS berdampingan dalam satu profil, dan berkas itu mulai tampak seperti tombol kekuatan dengan enam posisi. Padahal bukan. Setiap nama menjawab pertanyaan yang berbeda, dan dua profil yang berbeda pada salah satunya belum tentu lebih kuat atau lebih lemah satu sama lain. Mengurutkan nama berdasarkan pekerjaan yang dilakukannya memakan waktu sekitar lima menit dan mencegah sebagian besar perubahan buruk yang orang lakukan pada konfigurasi yang berfungsi.

Pengurutan di bawah ini dimulai dari kebingungan itu sendiri, lalu melebar ke luar menuju bagian-bagian profil yang benar-benar menentukan apa yang melindungi lalu lintas Anda. Setiap bagian mengambil satu kesalahan baca secara bergiliran dan menunjukkan apa yang sebenarnya dilekati nama itu.

Dua huruf, dua pertanyaan berbeda

Pasangan yang paling banyak menimbulkan perdebatan adalah EC dan ED, dan perdebatan itu biasanya menganggap keduanya jawaban yang bersaing atas satu pertanyaan. Keduanya bahkan tidak berada pada sumbu yang sama. EC menggambarkan sebuah keluarga matematika: kriptografi kurva elips, tempat keamanan berasal dari sulitnya logaritma diskret pada sebuah kurva, bukan di dalam medan berhingga yang besar.

ED menggambarkan bentuk kurva di dalam keluarga itu. Kurva Twisted Edwards adalah representasi yang dipilih demi kecepatan dan demi ketahanan terhadap beberapa kesalahan implementasi, dan Ed25519 adalah nama yang biasanya dimaksud orang. Kurva itu bukan pesaing kriptografi kurva elips; itu salah satu cara menuliskan kurva elips. Membaca ED sebagai "EC yang lebih baru dan lebih kuat" adalah belokan keliru pertama, dan semua yang menyusul cenderung keliru ke arah yang sama.

Penandatanganan dan pertukaran adalah pekerjaan terpisah

Setelah pertanyaan keluarga selesai, nama-nama yang tersisa terbagi ke dua kolom yang tidak pernah saling menggantikan. Satu kolom menandatangani, kolom lainnya menyepakati rahasia bersama.

EdDSA dan ECDSA sama-sama menandatangani, tetapi keduanya skema berbeda dengan format kunci berbeda, jadi sertifikat yang diterbitkan untuk salah satunya tidak dapat dipakai sebagai yang lain. EdDSA didefinisikan untuk sekumpulan kecil kurva; P-256 bukan salah satunya, karena itu sertifikat P-256 diverifikasi dengan ECDSA dan tidak pernah dengan Ed25519.

Kolom pertukaran tidak punya padanan bernama EdDH. Kesepakatan efemeral pada kunci Curve25519 adalah X25519, dan itu ECDH dengan kurva tertentu, persis seperti pada P-256. Ed25519 secara ketat berarti skema tanda tangan, meskipun namanya dipakai secara longgar untuk pertukaran karena kedua kurva saling terkait: bentuk Edwards yang dipakai untuk menandatangani dan bentuk Montgomery yang dipakai untuk X25519 menggambarkan grup dasar yang sama.

Mengapa profil EC tidak punya berkas dh

Berkas dh berisi parameter yang dibuat sebelumnya untuk Diffie-Hellman medan berhingga, dan parameter itu ada karena bilangan prima besar dan generator harus datang dari suatu tempat. Pertukaran kurva elips tidak membutuhkannya: kurva yang disebutkan adalah himpunan parameternya, dan kedua pihak sudah mengetahuinya. Itulah seluruh alasan profil EC dapat menghilangkan direktif tersebut.

Dua situasi masih menghasilkan baris dh pada profil yang sebaliknya tampak modern. Yang pertama adalah pendengar kedua atau rekan lama yang benar-benar merundingkan grup medan berhingga. Yang kedua adalah teks sisa yang disalin dari templat era RSA dan tidak pernah dihapus. Profil yang menyebut kurva untuk pertukaran dan masih memuat berkas dh 2048-bit tidak menjadi lebih aman karena melakukannya; ia membawa artefak yang tidak terpakai.

TLS 1.3 menghapus pertukaran kunci dari nama

Bandingkan TLS_AES_256_GCM_SHA384 dengan TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 dan nama yang lebih pendek tampak seperti penurunan. Ini penggantian nama, dan alasannya struktural: TLS 1.3 menghapus RSA statis dan pertukaran kunci Diffie-Hellman medan berhingga, sehingga pertukaran kurva elips efemeral adalah satu-satunya opsi non-PSK yang tersisa. Menyebutkannya di setiap suite akan mengulang fakta yang sama selusin kali.

Jenis sertifikat hilang dari nama karena alasan yang terkait. Pada 1.3 sertifikat mengautentikasi tanda tangan jabat tangan, bukan kesepakatan kunci, sehingga tidak lagi memilih suite. Itu juga sebabnya ada daftar cipher terpisah untuk 1.3 dalam konfigurasi: suite-nya diganti nama dan ditata ulang, bukan dilemahkan.

Satu konsekuensi layak dikatakan terus terang. ECDHE adalah algoritme pertukaran kunci dan tidak pernah cipher. Suite yang digambarkan sebagai "elips" mengatakan sesuatu tentang bagaimana kedua rekan mencapai kunci bersama, dan sama sekali tidak tentang apa yang kemudian mengenkripsi muatan.

auth mengautentikasi paket, bukan muatan

Direktif auth memilih digest HMAC yang mengautentikasi paket, dan nilai bawaannya secara historis adalah SHA1. Dengan cipher data non-AEAD, OpenVPN menghitung digest atas teks tersandi lalu menambahkannya, susunan enkripsi-lalu-MAC yang membuat manipulasi padding menjadi tidak praktis.

Mitos di sini adalah bahwa menaikkan auth ke SHA512 mengeraskan terowongan. Itu tidak menaikkan kekuatan enkripsi, dan jika cipher data yang dirundingkan adalah mode AEAD seperti AES-256-GCM, digest tidak diterapkan sama sekali pada paket data. Tag GCM sudah mengautentikasinya, dan nilai auth tersisa untuk HMAC kanal kendali dan untuk cipher non-AEAD yang masih dipakai.

Jadi direktif itu penting, tetapi penting di tempat yang lebih sempit daripada yang disiratkan posisinya dalam berkas. Memeriksa cipher mana yang benar-benar dirundingkan memberi tahu Anda apakah direktif itu berlaku sama sekali.

Baca profil per kolom, bukan per peringkat

Tiga pertanyaan memisahkan lapisan-lapisan itu dengan rapi, dan masing-masing dijawab oleh bagian sesi yang dirundingkan secara berbeda. Cipher mana yang melindungi muatan? Tag atau digest mana yang menjamin setiap paket, dan apakah cipher yang dipakai bahkan memerlukannya? Sertifikat siapa yang menutup jabat tangan, dan apakah kanal kendali juga dijaga oleh tls-auth atau tls-crypt?

Tidak ada apa pun pada label EC atau ED yang menyelesaikan salah satu dari ketiganya, dan nama suite sendirian juga tidak menyelesaikan satu pun. Hasil yang dirundingkan adalah satu-satunya bukti, jadi bacalah itu alih-alih menyimpulkan kekuatan dari kosakata:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Perintah pertama memberi tahu Anda skema tanda tangan mana yang benar-benar dipakai sertifikat Anda, dan itulah satu-satunya cara andal untuk mengetahui apakah Anda menjalankan ECDSA atau Ed25519. Perintah kedua menampilkan baris kanal kendali yang dicatat klien untuk sesi itu, termasuk versi TLS dan suite yang disepakati. Jika sebuah perubahan profil tidak dapat dibenarkan oleh salah satu dari dua keluaran itu, kemungkinan itu perubahan nama dan bukan perubahan sifat.