SECLEVEL=0 merawat simptom, bukan sijil

Sambungan OpenVPN gagal, seseorang menemui pembetulan satu baris yang menambah SECLEVEL=0, dan terowong naik. Yang berubah bukan sijil dan bukan suite sifer; ambang penerimaan seluruh pustaka beralih, dan segala yang dilakukan proses selepas itu mewarisi sempadan baharu. Perlu difahami sebelum baris yang sama disalin ke setiap profil dalam persekitaran.

Tentukan pustaka mana dan dasar mana yang berkuat kuasa

SECLEVEL ialah konsep OpenSSL, jadi soalan pertama ialah sama ada binaan anda menggunakan OpenSSL langsung. OpenVPN boleh dipautkan kepada lebih daripada satu pustaka kriptografi, dan tetapan yang terpakai kepada salah satunya tidak bermakna bagi yang lain. Tanya binari itu dengan apa ia dibina, kemudian tanya pustaka itu versi dan konfigurasi apa yang dimuatkannya:

openvpn --version | head -3
openssl version -a

Baca output versi dengan teliti, kerana pengedaran menampal nilai lalai. Sesetengah menghantar konfigurasi sistem yang menaikkan tahap minimum melebihi lalai upstream, dan itulah sebabnya profil yang sama berkelakuan berbeza pada dua mesin dengan pakej OpenVPN yang sama. Dasar berkesan ialah yang dimuatkan oleh proses yang berjalan, bukan yang dalam manual upstream.

Kemudian pisahkan dua lapisan yang dicampur orang. OpenVPN mempunyai kawalan TLS sendiri, termasuk tetapan profil sijil dan senarai sifer eksplisit, dan semuanya berada di atas apa sahaja yang dikuatkuasakan pustaka. Menurunkan tahap pustaka tidak mengubah sifer mana yang disenaraikan konfigurasi OpenVPN anda, dan menyempitkan senarai OpenVPN tidak menaikkan ambang pustaka. Mengetahui lapisan mana yang menolak anda itulah yang menghalang pembetulan daripada kekal sebagai tekaan.

Pisahkan tiga perkara yang boleh ditolak

Calon pertama ialah bahan identiti: sijil yang kuncinya terlalu kecil atau yang algoritma tandatangannya tidak lagi diterima dasar. Yang kedua ialah parameter pertukaran kunci, seperti kumpulan yang dianggap dasar terlalu lemah. Yang ketiga ialah suite sifer yang dikecualikan dasar. Ketiga-tiganya boleh menyebabkan kegagalan handshake, dan hanya teks ralat serta peringkat rundingan membezakannya.

Tiada satu pun daripada ketiga-tiganya ialah sifer saluran data. OpenVPN merundingkan penyulitan terowongnya secara berasingan daripada handshake TLS, jadi sambungan yang berjaya selepas perubahan tahap keselamatan tidak memberitahu apa-apa tentang sifer mana yang melindungi muatan anda. Jika soalan yang sebenarnya anda tanyakan ialah tentang kerahsiaan data, anda melihat dail yang sama sekali salah.

Menurunkan tahap meluaskan penerimaan untuk ketiga-tiga input sekali gus. Inilah bahagian yang orang terlepas: pembetulan yang menerima sijil lama juga menerima kumpulan lemah dan suite yang mungkin tidak anda niatkan untuk benarkan. Satu ralat mencetuskan perubahan, dan perubahan itu lebih luas daripada ralat itu. Asimetri inilah sebab pengecualian terhad lebih baik daripada nilai lalai untuk seluruh persekitaran.

Tukar input, bukan ambang

Simpan ralat yang tepat sebelum menyentuh konfigurasi, termasuk peringkat yang melaporkannya dan objek yang dinamakannya. Masalah sijil diselesaikan dengan menggantikan sijil itu dengan sesuatu yang diterima dasar semasa, yang biasanya bermaksud mengeluarkannya semula daripada pihak berkuasa dan bukannya memasang semula fail yang sama.

Jika input yang ditolak milik rakan yang tidak anda kawal, perbualan itu dengan pemiliknya tentang bahan gantian yang disokong. Menurunkan ambang anda sendiri untuk menampung sistem yang tidak dijaga sesiapa memindahkan kos daripada mereka kepada semua yang menyambung selepas mereka.

Di tempat pelayan menguatkuasakan dasar, semak sama ada tetapan peringkat OpenVPN ialah punca sebenar sebelum menyalahkan pustaka. Profil sijil yang meminta kelas lebih ketat daripada yang dapat dipenuhi sijil yang digunakan akan gagal walau apa pun tahap keselamatan, dan membuang profil itu ialah perubahan yang lebih sempit daripada mematikan pemeriksaan pustaka.

Jika perlu menurunkannya, hadkan dan catatkannya

Kadangkala pengecualian keserasian yang diluluskan ialah jawapan yang betul, terutamanya untuk rakan lama dengan pelan persaraan bertarikh. Hadkannya kepada perkhidmatan yang memerlukannya dan bukan seluruh hos: fail konfigurasi setiap perkhidmatan atau konfigurasi OpenSSL khusus mempunyai radius kesan yang lebih kecil daripada eksport dalam profil global.

Catat empat perkara bersama pengecualian itu: tetapan tepat, pemilik yang meluluskannya, klien yang terjejas, dan syarat ia ditarik balik. Pengecualian tanpa syarat persaraan ialah pelemahan kekal dengan justifikasi sementara yang dilampirkan.

Pengunduran sepatutnya satu langkah yang sudah anda uji. Simpan konfigurasi sebelumnya, gunakan perubahan, sahkan perkhidmatan bermula, dan ketahui dengan tepat fail mana untuk dipulihkan jika sambungan seterusnya berkelakuan berbeza daripada jangkaan.

Sahkan identiti dan perlindungan selepas itu

Sambungan yang berjaya hanya membuktikan bahawa syarat yang disemak semula menerimanya. Sahkan bahawa pengesahan nama hos dan rakan masih menjalankan tugasnya, sijil yang digunakan ialah yang anda niatkan untuk digunakan, dan saluran data yang dirundingkan sepadan dengan dasar yang anda fikir anda ada.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

Rujukan tahap keselamatan OpenSSL menyatakan dengan jelas bahawa rangka kerja itu mengenakan had pada kunci, tandatangan, kumpulan dan suite secara bersama, dan tahap sifar membenarkan semua yang diperiksa oleh panggil balik. Itulah skop apa yang anda ubah, dan itulah ayat yang dipetik apabila seseorang bertanya sama ada pembetulan itu sempit.

Penyerahan yang bertahan melalui audit menyatakan dasar mana yang menolak input mana, apa yang diubah, dan apa yang kekal diterima akibatnya. „Ia berfungsi dengan SECLEVEL=0“ ialah pemerhatian tentang satu sambungan, bukan penilaian keselamatan penggunaan.