Bolehkah sijil RSA berfungsi dengan dh none dalam OpenVPN?

Ini konfigurasi pelayan yang menyebut dh none di sebelah sijil yang menyebut RSA, serta syak yang mengganggu bahawa salah satunya mesti salah. Tiada apa yang salah. Sijil menandatangani dan mengesahkan; pertukaran kunci mewujudkan rahsia bersama. Itu dua tugas berbeza dalam handshake yang sama, dan TLS membenarkan sijil RSA mengesahkan handshake yang menggunakan persetujuan efemeral pada lengkung eliptik.

Kekeliruan biasanya datang bersama panduan migrasi. Ia menyuruh fail parameter DH diganti dengan dh none, pembaca menyedari sijil itu bukan sijil lengkung eliptik, dan kedua-dua fakta dianggap percanggahan.

Mengapa kedua-dua tetapan kelihatan berkaitan

Konfigurasi OpenVPN yang lebih lama meminta fail parameter DH kerana Diffie-Hellman medan terhingga memerlukan parameter domain yang dipersetujui kedua-dua pihak. Arahan dh menunjuk ke fail itu. Apabila penggunaan beralih ke ECDH, parameter datang daripada lengkung bernama, dan fail itu tidak lagi diperlukan, yang dinyatakan oleh dh none.

Sijil ialah paksi berasingan. Ia membawa kunci awam dan tandatangan yang membuktikan identiti pelayan, dan kunci itu boleh menjadi RSA atau lengkung eliptik tanpa mengira bagaimana kunci sesi dipersetujui. Handshake yang menggunakan ECDHE untuk persetujuan kunci dan RSA untuk pengesahan adalah biasa dan digunakan secara meluas.

Penamaan memburukkan pertindihan. Lengkung eliptik muncul dalam nama suite ECDHE dan ECDSA, jadi mudah menganggap bahawa mana-mana sambungan yang menyebut lengkung mesti melibatkan sijil lengkung. Tidak begitu.

Membaca nama suite TLS 1.2 dengan betul

Ambil ECDHE-RSA-AES256-GCM-SHA384. Token pertama ialah keluarga pertukaran kunci: Diffie-Hellman efemeral pada lengkung eliptik. Yang kedua ialah keluarga pengesahan: RSA. Selebihnya menerangkan perlindungan rekod dan hash yang digunakan dalam handshake.

Suite ECDHE-ECDSA menggunakan keluarga pertukaran kunci yang sama dengan kaedah pengesahan berbeza, jadi ia memerlukan sijil lengkung eliptik. Suite DHE-RSA menggunakan Diffie-Hellman efemeral medan terhingga dengan pengesahan RSA, dan yang itu memang memerlukan parameter DH.

Baca nama suite dari kiri ke kanan dan tetapkan setiap bahagian kepada tugasnya. Selepas token dipisahkan, soalan berubah daripada «adakah sijil saya sepadan dengan dh none» kepada «adakah pelayan saya membenarkan suite yang pertukaran kuncinya tidak memerlukan fail DH».

Apa yang sebenarnya dinyahdayakan oleh dh none

dh none memberitahu pelayan supaya tidak memuatkan fail parameter DH medan terhingga. Ia tidak menyahdayakan pengesahan, pengesahan sijil atau TLS itu sendiri. Namun ia memerlukan pertukaran kunci yang dirundingkan tidak memerlukan parameter tersebut, yang dalam praktiknya bermaksud suite ECDHE atau handshake TLS 1.3.

Daripada keperluan itulah kerosakan berlaku. Jika dasar sifer TLS pelayan terhad kepada suite DHE, atau klien hanya menawarkan itu, membuang fail parameter tidak meninggalkan kaedah pertukaran kunci yang boleh digunakan dan handshake gagal. Ralat biasanya muncul semasa handshake saluran kawalan, sebelum sebarang pengesahan pengguna. Baca senarai sifer sebelum menyalahkan fail yang hilang.

Di sisi lengkung eliptik, lengkung dipilih oleh konfigurasi TLS pelayan, dan OpenVPN menawarkan pilihan untuk memilihnya pada cabang lama. TLS 1.3 mengendalikan rundingan kumpulan di dalam protokol dan tidak merujuk fail DH sama sekali.

dh none bukan penurunan keselamatan dengan sendirinya. Kekuatan pertukaran kemudian bergantung pada lengkung dan suite yang benar-benar dirundingkan, sebab itu langkah seterusnya ialah melihat apa yang dipilih oleh rakan sebaya, bukan fail yang tiada.

Mengesahkan rundingan sebelum menyunting

Tingkatkan verbositi pelayan dan klien serta baca baris saluran kawalan yang dicetak OpenVPN selepas sambungan. Ia menamakan versi TLS dan sifer yang dirundingkan, dan melaporkan jenis kunci sijil rakan. Baris tunggal itu menjawab soalan yang hanya diisyaratkan oleh fail konfigurasi.

Jika ia menunjukkan TLS 1.2 dengan suite ECDHE-RSA dan sijil RSA, gabungan itu tepat seperti yang dijangka dh none, dan tiada apa yang perlu dibaiki. Jika ia menunjukkan suite DHE atau kegagalan handshake tanpa sifer bersama, pembaikan terletak pada dasar sifer atau keupayaan klien, bukan pada sijil.

Uji klien tertua yang ingin anda sokong, kerana klien semasa mungkin merundingkan TLS 1.3 manakala yang lebih lama terhad kepada suite TLS 1.2. Jika klien tertua tiada pertindihan, sama ada luaskan suite yang dibenarkan atau naik taraf titik akhir itu.

Jangan matikan pengesahan sijil untuk melepasi kegagalan handshake. Kegagalan itu memberitahu anda bahawa rakan sebaya tidak dapat bersetuju tentang pertukaran kunci, dan mematikan pemeriksaan menghapuskan jaminan identiti tanpa menyelesaikan persetujuan.

Senarai semak: adakah sijil itu RSA, adakah suite ECDHE dibenarkan, adakah log menunjukkan suite itu, dan adakah klien tertua yang disokong juga merundingkannya? Jika keempat-empatnya ya, dh none menjalankan tugasnya.