Gesaan kunci OpenVPN selepas OpenSSL 3: periksa penyedianya

Tiada siapa menyentuh profil itu, namun klien yang sama kini meminta frasa laluan untuk kunci peribadi setiap kali ia bermula. Apabila perubahan itu berlaku dalam beberapa hari selepas peningkatan pengedaran, peningkatan itulah punca yang mungkin: OpenSSL 3 menyusun semula sokongan algoritmanya, dan kunci yang dibaca lancar oleh pustaka lama boleh menjadi tidak terbaca tanpa satu bait pun berubah. Lakukan pemeriksaan mengikut urutan, kerana dua daripadanya kelihatan sama jika anda hanya melihat gesaan itu.

Soalan pertama ialah sama ada kunci itu disulitkan, dan yang kedua ialah sama ada binaan ini boleh menyahsulitkannya. Perubahan konfigurasi hanya bermakna setelah kedua-dua jawapan diketahui.

Periksa sama ada kunci itu disulitkan

Baca baris pertama fail itu dan kemudian biarkan pustaka menghuraikannya, kerana nama fail tidak membuktikan apa-apa. Blok PEM berlabel ENCRYPTED PRIVATE KEY ialah PKCS#8 tersulit, dan blok RSA PRIVATE KEY yang lebih lama yang membawa Proc-Type: 4,ENCRYPTED ialah bentuk tradisional, dan kedua-duanya menjangka frasa laluan. Blok PRIVATE KEY yang tidak disulitkan sepatutnya tidak meminta langsung. Jalankan penghuraian sebagai akaun yang memiliki fail itu, kerana masalah kebenaran menghasilkan ralat yang berbeza dan jauh kurang menarik.

Jika kunci itu benar-benar tidak disulitkan dan klien masih bertanya, berhenti melihat kriptografi dan periksa sama ada profil itu menamakan fail askpass yang masih boleh dibaca oleh perkhidmatan.

Periksa sama ada binaan ini boleh menyahsulitkannya

OpenSSL 3 membahagikan sokongan algoritmanya kepada penyedia, dan satu set sifer lama kini berada dalam penyedia legacy dan bukan yang lalai. Kunci yang disulitkan dengan salah satu sifer itu kekal sah, tetapi pustaka yang dimuatkan tanpa penyedia legacy tidak dapat menyahkodnya. Pada sesetengah klien itu muncul sebagai gesaan yang berulang, pada yang lain sebagai kegagalan keras sejurus selepas frasa laluan.

Huraikan kunci yang sama dua kali dengan binari yang sama: pertama dengan penyedia lalai sahaja, kemudian dengan legacy dan lalai kedua-duanya diminta pada baris arahan. Jika percubaan kedua berjaya di tempat percubaan pertama gagal, diagnosis itu berpandukan bukti dan bukan masa peningkatan. Jika kedua-duanya gagal dengan cara yang sama, frasa laluan itu salah atau fail itu rosak, dan tiada tetapan penyedia membaiki mana-mana daripadanya.

Periksa pembetulan paling sempit yang tersedia

Utamakan perubahan yang terhad kepada klien berbanding perubahan seluruh sistem. Sesetengah binaan 2.6 menerima pilihan profil yang memuatkan kedua-dua penyedia untuk proses daemon itu, jadi sahkan direktif itu dalam manual bagi versi tepat anda sebelum bergantung padanya; menyunting openssl.cnf sistem sebaliknya menjejaskan setiap program OpenSSL pada hos. Tetapan yang lebih sempit juga jauh lebih mudah untuk dibatalkan setelah kunci dikodkan semula.

Jangan padam frasa laluan semata-mata untuk menghilangkan gesaan itu. Itu menukar kelayakan yang dilindungi menjadi fail teks biasa dan secara senyap mengubah risiko setiap sandaran, salinan dan bundel sokongan tempat ia muncul. Perbezaan yang penting ialah antara kunci yang memerlukan frasa laluannya dan kunci yang tidak dapat dinyahkod oleh pustaka ini.

Periksa konteks perkhidmatan, kemudian kodkan semula

Setelah kunci itu boleh dibuka, sulitkan semula dengan algoritma semasa supaya kebergantungan itu hilang. Tulis fail baharu dengan sifer moden, sahkan bahawa ia dihuraikan, kemas kini profil, dan simpan salinan lama hanya sehingga sambungan berjaya. Jangan sekali-kali meletakkan frasa laluan pada baris arahan, tempat mana-mana pengguna setempat boleh membacanya daripada senarai proses. Buang fail lama hanya selepas yang baharu bersambung daripada akaun perkhidmatan, bukan hanya daripada shell anda.

Kemudian periksa unit yang benar-benar menjalankan klien. Kunci yang boleh dibaca dalam shell anda mungkin tidak boleh dibaca oleh perkhidmatan yang berjalan di bawah akaun lain atau dengan tetapan direktori rumah yang dikeraskan.

Catatkan tetapan penyedia di sebelah profil dan simpan ujian dua arahan bersamanya. Apabila peningkatan kemudiannya menggugurkan penyedia legacy, jalankan semula ujian itu untuk melihat sama ada kunci itu masih memerlukannya atau profil itu boleh dikeluarkan daripada penyelesaian sementara ini.

Gesaan ialah gejala dengan sekurang-kurangnya tiga punca, dan hanya satu daripadanya ialah frasa laluan yang hilang.