Ralat ini muncul sebelum gesaan kata laluan, dan itulah bahagian yang berguna: belum ada apa-apa yang disahkan, jadi bukti kelayakan bukan masalahnya. Pada Linux, dialog AnyConnect yang sama boleh datang daripada versi protokol lama, kumpulan pertukaran kunci 1024 bit, atau suite sifer yang ditolak oleh dasar kripto sistem. Saya telah menghapuskannya dengan tiga cara berbeza pada tiga mesin, dan yang membezakan pembaikan itu ialah skop kesannya, bukan kepintarannya. Setiap satu wajar di tempat yang betul dan lalai yang buruk di tempat lain.

Baca mesej sebelum menyentuh dasar

Simpan rentetan tepat daripada dialog itu. Aduan versi menunjuk lapisan protokol, aduan sijil menunjuk kepercayaan atau penamaan, dan log masuk gagal menunjuk bukti kelayakan. Gateway yang menawarkan TLS 1.0 dengan kumpulan DHE 1024 bit, AES-256-CBC dan tandatangan SHA-1 boleh mempunyai sijil yang sah sepenuhnya dan masih ditolak oleh dasar moden sebelum bukti kelayakan anda dihantar.

Periksa titik akhir dengan OpenSSL sistem, menggunakan nama hos sebenar dan port yang digunakan oleh klien.

Kegagalan openssl s_client -connect vpn.example.com:443 -servername vpn.example.com manakala -tls1 -cipher DEFAULT@SECLEVEL=0 berjaya menunjukkan bahawa hadnya ialah versi dan saiz kunci bersama-sama. Jika arahan pertama melaporkan kunci DH kecil dan bukan amaran protokol, versinya baik dan hanya kumpulan itu memerlukan perhatian. Jangan sekali-kali meletakkan kunci persendirian atau kata laluan dalam pemeriksaan.

Pilihan 1: longgarkan seluruh hos dengan dasar kripto

Pada Fedora dan RHEL 8 dan 9, update-crypto-policies --set LEGACY menurunkan dasar sistem OpenSSL, dan update-crypto-policies --show mengesahkan apa yang aktif. Ia biasanya memulihkan terowong, tetapi dasar dibaca apabila proses bermula, jadi mulakan semula klien dan mana-mana pembantu yang diciptanya sebelum menguji semula. Ia juga membenarkan protokol lama dan kumpulan yang lebih lemah untuk setiap klien TLS pada mesin itu, daripada pelayar di tetingkap sebelah hingga pengurus pakej yang mengemas kini kernel.

Keluasan itulah seluruh tujuan dan seluruh masalahnya. LEGACY terpakai pada seluruh hos, berterusan dan mudah dilupakan, jadi ia wajar menjadi langkah diagnostik atau pengecualian terdokumen pada binaan terurus, tidak pernah menjadi keadaan rehat sesebuah stesen kerja. Saya pernah melihat satu yang kekal pada LEGACY selama dua tahun kerana satu portal dalaman memerlukannya, dan tiada siapa dapat mengatakan bila ia bermula.

Debian dan Ubuntu tiada satu suis untuk ini. Persamaannya ialah suntingan pada /etc/ssl/openssl.cnf yang menetapkan MinProtocol lebih rendah dan CipherString = DEFAULT@SECLEVEL=0 dalam bahagian lalai sistem. Skop sama, fail berbeza, sedikit lebih mudah hilang dari pandangan semasa peningkatan keluaran.

Pilihan 2: satu fail konfigurasi untuk satu klien

Konfigurasi OpenSSL setiap proses menyimpan perubahan dalam satu pokok proses, tetapi hanya jika fail itu diraup seperti yang dijangka oleh pustaka. Menamakan bahagian ssl_conf tidak mencukupi: OpenSSL membaca kunci peringkat atas openssl_conf, mengikutinya ke bahagian init, dan hanya kemudian mencapai lalai SSL.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

Halakan OPENSSL_CONF ke fail itu dan lancarkan klien VPN melalui pembalut yang mengeksportnya. Semua yang lain pada hos mengekalkan dasar lalai, dan itulah sifat yang penting apabila soalan pematuhan datang. Pastikan fail itu benar-benar berkuat kuasa sebelum menyalahkan gateway: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 sepatutnya menyenaraikan sifer TLS 1.0, dan hasil kosong bermakna rantaian itu terputus dan klien secara senyap mengekalkan lalai sistem.

Fail itu sensitif kepada versi. OpenSSL 1.1.1 dan 3.x menerima nama bahagian yang sama, tetapi pengendalian arahan sekitar penyedia berubah dalam 3.x, jadi sahkan dengan log klien sendiri dan jabat tangan ujian dan bukannya menganggap fail itu telah dibaca. Salah taip dalam nama bahagian gagal secara terbuka, dan klien secara senyap menggunakan lalai sistem.

Hadnya ialah liputan. Apa sahaja yang dipautkan kepada GnuTLS atau NSS mengabaikan OPENSSL_CONF, begitu juga mana-mana proses pembantu yang dilancarkan klien tanpa mewarisi persekitaran. Periksa dengan ldd pustaka TLS mana yang sebenarnya dipautkan oleh binari sebelum membina pembalut, kerana jawapannya menentukan sama ada pilihan ini wujud sama sekali.

Pilihan 3: VM atau kontena sekali guna

Bagi kontraktor yang selama dua minggu menyerang satu gateway lama, VM khusus dengan dasar yang dilonggarkan ialah sempadan yang lebih bersih daripada stesen kerja. Permukaan lama dan profil pelayar harian berhenti berkongsi dasar kernel, dan pelupusan ialah pemadaman, bukan penemuan audit.

Ia masih mesin dalam rangkaian, jadi hadkan aksesnya dan jauhkan daripada pelayaran umum. Kos penyelenggaraan ialah satu lagi imej untuk ditampal, yang nyata tetapi terhad dan kelihatan, tidak seperti bendera LEGACY yang terlupa pada komputer riba.

Apa yang ditinggalkan perbandingan itu

Pilih dengan tiga soalan: siapa yang memerlukan protokol lama, berapa lama, dan siapa yang akan perasan jika pengecualian itu hidup lebih lama daripada alasannya. Satu aplikasi, satu orang, beberapa hari menunjuk kepada konfigurasi setiap proses. Seluruh armada di belakang satu peranti menunjuk kepada gateway itu sendiri. Apa sahaja yang memerlukan dasar LEGACY kekal pada hos ialah keputusan perolehan yang memakai kostum teknikal.

Pembaikan tahan lama terletak pada peranti: TLS 1.2 atau lebih baru, kumpulan sekurang-kurangnya 2048 bit, sifer AEAD, dan sijil dengan tandatangan moden. Mintalah perubahan itu daripada pemilik peranti, kemudian sahkan versi dan sifer yang dirundingkan dalam log klien. Tuliskan pengecualian itu bersama hos, gateway, protokol yang dirundingkan, pemberi kelulusan dan tarikh luput, kerana catatan itulah yang menghalang penyelesaian sementara daripada menjadi lalai.

Artikel berkaitan