Versi TLS tidak sah di AnyConnect pada Linux: tentukan dulu cakupan perbaikannya

Galat ini muncul sebelum permintaan kata sandi, dan itulah bagian yang berguna: belum ada yang diautentikasi, jadi kredensial bukan masalahnya. Di Linux, dialog AnyConnect yang sama bisa berasal dari versi protokol lama, grup pertukaran kunci 1024 bit, atau suite cipher yang ditolak kebijakan kripto sistem. Saya telah menghapusnya dengan tiga cara berbeda di tiga mesin, dan yang membedakan perbaikan itu adalah cakupan dampaknya, bukan kepintarannya. Masing-masing masuk akal di tempat yang tepat dan pilihan bawaan buruk di tempat lain.

Baca pesannya sebelum menyentuh kebijakan

Simpan string persisnya dari dialog. Keluhan versi menunjuk lapisan protokol, keluhan sertifikat menunjuk kepercayaan atau penamaan, dan login gagal menunjuk kredensial. Gateway yang menawarkan TLS 1.0 dengan grup DHE 1024 bit, AES-256-CBC, dan tanda tangan SHA-1 bisa memiliki sertifikat yang sepenuhnya sah dan tetap ditolak kebijakan modern sebelum kredensial Anda dikirim.

Periksa endpoint dengan OpenSSL sistem, memakai nama host sebenarnya dan port yang dipakai klien.

Kegagalan openssl s_client -connect vpn.example.com:443 -servername vpn.example.com sementara -tls1 -cipher DEFAULT@SECLEVEL=0 berhasil menunjukkan bahwa batasnya adalah versi dan ukuran kunci sekaligus. Jika perintah pertama melaporkan kunci DH kecil alih-alih peringatan protokol, versinya baik dan hanya grupnya yang perlu diperhatikan. Jangan pernah menaruh kunci privat atau kata sandi dalam pemeriksaan.

Opsi 1: longgarkan seluruh host dengan kebijakan kripto

Di Fedora dan RHEL 8 dan 9, update-crypto-policies --set LEGACY menurunkan kebijakan sistem OpenSSL, dan update-crypto-policies --show memastikan apa yang aktif. Ini biasanya memulihkan tunnel, tetapi kebijakan dibaca saat proses mulai, jadi jalankan ulang klien dan setiap pembantu yang dibuatnya sebelum menguji lagi. Ini juga mengizinkan protokol lama dan grup yang lebih lemah bagi setiap klien TLS di mesin, dari peramban di jendela sebelah hingga manajer paket yang memperbarui kernel.

Keluasan itulah seluruh tujuannya dan seluruh masalahnya. LEGACY berlaku untuk seluruh host, bertahan lama, dan mudah dilupakan, jadi seharusnya menjadi langkah diagnostik atau pengecualian terdokumentasi pada build terkelola, bukan keadaan diam sebuah workstation. Saya pernah melihat satu yang bertahan di LEGACY selama dua tahun karena satu portal internal membutuhkannya, dan tidak ada yang bisa mengatakan kapan itu dimulai.

Debian dan Ubuntu tidak punya satu sakelar untuk ini. Padanannya adalah penyuntingan /etc/ssl/openssl.cnf yang menetapkan MinProtocol lebih rendah dan CipherString = DEFAULT@SECLEVEL=0 di bagian bawaan sistem. Cakupan sama, berkas berbeda, sedikit lebih mudah hilang dari pandangan saat peningkatan rilis.

Opsi 2: satu berkas konfigurasi untuk satu klien

Konfigurasi OpenSSL per proses menjaga perubahan di dalam satu pohon proses, tetapi hanya jika berkasnya dirangkai seperti yang diharapkan pustaka. Menamai bagian ssl_conf tidak cukup: OpenSSL membaca kunci tingkat atas openssl_conf, mengikutinya ke bagian init, dan baru kemudian mencapai bawaan 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

Arahkan OPENSSL_CONF ke berkas itu dan jalankan klien VPN melalui pembungkus yang mengekspornya. Semua hal lain di host tetap memakai kebijakan bawaan, dan itulah sifat yang penting ketika pertanyaan kepatuhan datang. Pastikan berkas benar-benar berlaku sebelum menyalahkan gateway: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 seharusnya mencantumkan cipher TLS 1.0, dan hasil kosong berarti rantainya putus dan klien diam-diam mempertahankan bawaan sistem.

Berkas itu sensitif terhadap versi. OpenSSL 1.1.1 dan 3.x menerima nama bagian yang sama, tetapi penanganan direktif di sekitar penyedia berubah di 3.x, jadi verifikasi dengan log klien sendiri dan handshake uji alih-alih menganggap berkasnya terbaca. Salah ketik pada nama bagian gagal terbuka, dan klien diam-diam memakai bawaan sistem.

Batasnya adalah cakupan. Apa pun yang ditautkan ke GnuTLS atau NSS mengabaikan OPENSSL_CONF, begitu juga setiap proses pembantu yang dijalankan klien tanpa mewarisi lingkungan. Periksa dengan ldd pustaka TLS mana yang benar-benar ditautkan biner sebelum membangun pembungkus, karena jawabannya menentukan apakah opsi ini ada sama sekali.

Opsi 3: VM atau kontainer sekali pakai

Bagi kontraktor yang selama dua pekan menghantam satu gateway lama, VM khusus dengan kebijakan yang dilonggarkan adalah batas yang lebih bersih daripada workstation. Permukaan lama dan profil peramban sehari-hari berhenti berbagi kebijakan kernel, dan pembuangannya adalah penghapusan, bukan temuan audit.

Itu masih mesin berjaringan, jadi batasi aksesnya dan jauhkan dari peramban umum. Biaya pemeliharaannya adalah satu image lagi untuk ditambal, yang nyata tetapi terbatas dan terlihat, tidak seperti bendera LEGACY yang terlupakan di laptop.

Apa yang ditinggalkan perbandingan itu

Pilih dengan tiga pertanyaan: siapa yang membutuhkan protokol lama, berapa lama, dan siapa yang akan menyadarinya jika pengecualian itu hidup lebih lama dari alasannya. Satu aplikasi, satu orang, beberapa hari mengarah ke konfigurasi per proses. Seluruh armada di balik satu perangkat mengarah ke gateway itu sendiri. Apa pun yang membutuhkan kebijakan LEGACY permanen di host adalah keputusan pengadaan yang memakai kostum teknis.

Perbaikan tahan lama ada pada perangkat: TLS 1.2 atau lebih baru, grup minimal 2048 bit, cipher AEAD, dan sertifikat dengan tanda tangan modern. Mintalah perubahan itu kepada pemilik perangkat, lalu pastikan versi dan cipher yang dinegosiasikan di log klien. Tuliskan pengecualian itu bersama host, gateway, protokol yang dinegosiasikan, pemberi persetujuan, dan tanggal kedaluwarsa, karena catatan itulah yang mencegah solusi sementara menjadi bawaan.