Bisakah sertifikat RSA bekerja dengan dh none di OpenVPN?

Ini konfigurasi server yang menyebut dh none di samping sertifikat yang menyebut RSA, plus kecurigaan mengganggu bahwa salah satunya pasti salah. Tidak ada yang salah. Sertifikat menandatangani dan mengautentikasi; pertukaran kunci membentuk rahasia bersama. Itu dua pekerjaan berbeda dalam handshake yang sama, dan TLS memungkinkan sertifikat RSA mengautentikasi handshake yang memakai kesepakatan efemeral pada kurva eliptik.

Kebingungan biasanya datang bersama panduan migrasi. Panduan itu menyuruh mengganti berkas parameter DH dengan dh none, pembaca menyadari sertifikat itu bukan sertifikat kurva eliptik, dan kedua fakta dianggap sebagai kontradiksi.

Mengapa kedua pengaturan tampak terkait

Konfigurasi OpenVPN yang lebih lama meminta berkas parameter DH karena Diffie-Hellman medan berhingga membutuhkan parameter domain yang disepakati kedua pihak. Direktif dh menunjuk ke berkas itu. Ketika penerapan beralih ke ECDH, parameternya berasal dari kurva bernama, dan berkasnya tidak lagi diperlukan, yang dinyatakan oleh dh none.

Sertifikat adalah sumbu terpisah. Sertifikat membawa kunci publik dan tanda tangan yang membuktikan identitas server, dan kunci itu dapat berupa RSA atau kurva eliptik terlepas dari bagaimana kunci sesi disepakati. Handshake yang memakai ECDHE untuk kesepakatan kunci dan RSA untuk autentikasi adalah hal biasa dan diterapkan secara luas.

Penamaan memperburuk tumpang tindih. Kurva eliptik muncul di nama suite ECDHE maupun ECDSA, jadi mudah menganggap bahwa setiap koneksi yang menyebut kurva pasti melibatkan sertifikat kurva. Tidak demikian.

Membaca nama suite TLS 1.2 dengan benar

Ambil ECDHE-RSA-AES256-GCM-SHA384. Token pertama adalah keluarga pertukaran kunci: Diffie-Hellman efemeral pada kurva eliptik. Yang kedua adalah keluarga autentikasi: RSA. Sisanya menjelaskan perlindungan rekaman dan hash yang dipakai dalam handshake.

Suite ECDHE-ECDSA memakai keluarga pertukaran kunci yang sama dengan metode autentikasi berbeda, jadi memerlukan sertifikat kurva eliptik. Suite DHE-RSA memakai Diffie-Hellman efemeral medan berhingga dengan autentikasi RSA, dan yang itu memang memerlukan parameter DH.

Baca nama suite dari kiri ke kanan dan tetapkan setiap bagian pada tugasnya. Setelah token dipisahkan, pertanyaannya berubah dari «apakah sertifikat saya cocok dengan dh none» menjadi «apakah server saya mengizinkan suite yang pertukaran kuncinya tidak memerlukan berkas DH».

Apa yang sebenarnya dinonaktifkan dh none

dh none memberi tahu server untuk tidak memuat berkas parameter DH medan berhingga. Itu tidak menonaktifkan autentikasi, validasi sertifikat, atau TLS itu sendiri. Yang diperlukan adalah pertukaran kunci yang dinegosiasikan tidak membutuhkan parameter tersebut, yang dalam praktik berarti suite ECDHE atau handshake TLS 1.3.

Dari persyaratan itulah kerusakan muncul. Jika kebijakan cipher TLS server dibatasi pada suite DHE, atau klien hanya menawarkan suite itu, menghapus berkas parameter tidak menyisakan metode pertukaran kunci yang dapat dipakai dan handshake gagal. Galat biasanya muncul selama handshake saluran kontrol, sebelum autentikasi pengguna apa pun. Baca daftar cipher sebelum menyalahkan berkas yang hilang.

Di sisi kurva eliptik, kurva dipilih oleh konfigurasi TLS server, dan OpenVPN menyediakan opsi untuk memilihnya pada cabang lama. TLS 1.3 menangani negosiasi grup di dalam protokol dan sama sekali tidak memeriksa berkas DH.

dh none bukan penurunan keamanan dengan sendirinya. Kekuatan pertukaran lalu bergantung pada kurva dan suite yang benar-benar dinegosiasikan, itulah sebabnya langkah berikutnya adalah melihat apa yang dipilih para peer, bukan berkas yang tidak ada.

Memastikan negosiasi sebelum menyunting

Naikkan verbositas server dan klien serta baca baris saluran kontrol yang dicetak OpenVPN setelah koneksi. Baris itu menyebut versi TLS dan cipher yang dinegosiasikan, dan melaporkan jenis kunci sertifikat peer. Satu baris itu menjawab pertanyaan yang hanya tersirat oleh berkas konfigurasi.

Jika menampilkan TLS 1.2 dengan suite ECDHE-RSA dan sertifikat RSA, kombinasinya persis seperti yang diharapkan dh none, dan tidak ada yang perlu diperbaiki. Jika menampilkan suite DHE atau kegagalan handshake tanpa cipher bersama, perbaikannya ada pada kebijakan cipher atau kemampuan klien, bukan pada sertifikat.

Uji klien tertua yang ingin Anda dukung, karena klien saat ini mungkin menegosiasikan TLS 1.3 sementara klien lama terbatas pada suite TLS 1.2. Jika klien tertua tidak memiliki tumpang tindih, perluas suite yang diizinkan atau tingkatkan titik akhir itu.

Jangan menonaktifkan verifikasi sertifikat untuk melewati kegagalan handshake. Kegagalan itu memberi tahu Anda bahwa para peer tidak dapat menyepakati pertukaran kunci, dan menonaktifkan pemeriksaan menghilangkan jaminan identitas tanpa menyelesaikan kesepakatan.

Daftar periksa: apakah sertifikatnya RSA, apakah suite ECDHE diizinkan, apakah log menampilkan suite itu, dan apakah klien tertua yang didukung juga menegosiasikannya? Jika keempatnya ya, dh none menjalankan tugasnya.