Linux'ta AnyConnect'in geçersiz TLS sürümü: önce düzeltmenin kapsamını belirleyin

Bu hata parola isteminden önce gelir ve işe yarayan kısım da budur: henüz hiçbir şey kimliği doğrulanmadı, yani sorun kimlik bilgileri değil. Linux'ta aynı AnyConnect penceresi eski bir protokol sürümünden, 1024 bitlik bir anahtar değişimi grubundan veya sistemin kripto ilkesinin reddettiği bir şifre paketinden gelebilir. Bunu üç makinede üç farklı şekilde giderdim ve bu düzeltmeleri ayıran şey kurnazlık değil, etki alanıdır. Her biri doğru yerde savunulabilir, başka her yerde ise kötü bir varsayılandır.

İlkeye dokunmadan önce mesajı okuyun

Penceredeki tam dizeyi saklayın. Sürüm şikâyeti protokol katmanına, sertifika şikâyeti güvene veya adlandırmaya, başarısız oturum açma ise kimlik bilgilerine işaret eder. TLS 1.0'ı 1024 bitlik DHE grubu, AES-256-CBC ve SHA-1 imzasıyla sunan bir ağ geçidi tamamen geçerli bir sertifikaya sahip olabilir ve yine de kimlik bilgileriniz gönderilmeden önce modern bir ilke tarafından reddedilebilir.

Uç noktayı sistemin OpenSSL'iyle, gerçek ana makine adını ve istemcinin kullandığı bağlantı noktasını kullanarak sorgulayın.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com başarısız olurken -tls1 -cipher DEFAULT@SECLEVEL=0 başarılıysa sınır hem sürüm hem anahtar boyutudur. İlk komut protokol uyarısı yerine küçük bir DH anahtarı bildirirse sürüm iyidir ve yalnızca gruba dikkat etmek gerekir. Denetimin içine asla özel anahtar veya parola koymayın.

Seçenek 1: kripto ilkesiyle tüm ana makineyi gevşetin

Fedora ve RHEL 8 ve 9'da update-crypto-policies --set LEGACY OpenSSL'in sistem ilkesini düşürür ve update-crypto-policies --show neyin etkin olduğunu doğrular. Bu genellikle tüneli geri getirir, ancak ilke bir süreç başladığında okunur, bu yüzden yeniden test etmeden önce istemciyi ve oluşturduğu her yardımcı süreci yeniden başlatın. Ayrıca makinedeki her TLS istemcisi için eski protokollere ve daha zayıf gruplara izin verir; yan penceredeki tarayıcıdan çekirdeği güncelleyen paket yöneticisine kadar.

Bu genişlik hem bütün amaç hem bütün sorundur. LEGACY tüm ana makine için geçerlidir, kalıcıdır ve unutulması kolaydır, bu yüzden yönetilen bir yapıda tanılama adımı veya belgelenmiş bir istisna olmalı, asla bir iş istasyonunun dinlenme durumu olmamalıdır. Tek bir iç portal gerektirdiği için iki yıl LEGACY'de kalan bir tane gördüm ve kimse ne zaman başladığını söyleyemedi.

Debian ve Ubuntu'nun bunun için tek bir anahtarı yoktur. Eşdeğeri, sistem varsayılanları bölümünde daha düşük bir MinProtocol ve CipherString = DEFAULT@SECLEVEL=0 ayarlayan /etc/ssl/openssl.cnf düzenlemesidir. Aynı etki alanı, farklı dosya, sürüm yükseltmesi sırasında gözden kaçırması biraz daha kolay.

Seçenek 2: bir istemci için tek yapılandırma dosyası

Süreç başına OpenSSL yapılandırması değişikliği tek bir süreç ağacının içinde tutar, ancak dosya kütüphanenin beklediği şekilde bağlanmışsa. ssl_conf bölümünü adlandırmak yetmez: OpenSSL en üst düzeydeki openssl_conf anahtarını okur, onu bir başlatma bölümüne kadar izler ve ancak ondan sonra SSL varsayılanlarına ulaşır.

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

OPENSSL_CONF değişkenini o dosyaya yönlendirin ve VPN istemcisini onu dışa aktaran bir sarmalayıcı üzerinden başlatın. Ana makinedeki diğer her şey varsayılan ilkeyi korur ve uyumluluk sorusu geldiğinde önemli olan özellik budur. Ağ geçidini suçlamadan önce dosyanın gerçekten yürürlükte olduğunu doğrulayın: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 TLS 1.0 şifrelerini listelemelidir ve boş bir sonuç zincirin koptuğu ve istemcinin sessizce sistem varsayılanlarını koruduğu anlamına gelir.

Dosya sürüme duyarlıdır. OpenSSL 1.1.1 ve 3.x aynı bölüm adlarını kabul eder, ancak sağlayıcılar etrafındaki yönerge işleme 3.x'te değişti, bu yüzden dosyanın okunduğunu varsaymak yerine istemcinin kendi günlüğü ve bir test el sıkışmasıyla doğrulayın. Bölüm adındaki yazım hatası açık şekilde başarısız olur ve istemci sessizce sistem varsayılanlarını kullanır.

Sınır kapsamdır. GnuTLS veya NSS ile bağlanmış her şey OPENSSL_CONF değişkenini yok sayar; istemcinin ortamı devralmadan başlattığı her yardımcı süreç de öyle. Sarmalayıcıyı kurmadan önce ldd ile ikili dosyanın gerçekte hangi TLS kütüphanesine bağlandığını denetleyin, çünkü yanıt bu seçeneğin var olup olmadığını belirler.

Seçenek 3: tek kullanımlık bir VM veya konteyner

İki hafta boyunca tek bir eski ağ geçidine saldıran bir yüklenici için gevşetilmiş ilkeye sahip ayrı bir VM, iş istasyonundan daha temiz bir sınırdır. Eski yüzey ve günlük tarayıcı profili artık bir çekirdek ilkesini paylaşmaz ve imha, denetim bulgusu değil silmedir.

Hâlâ ağdaki bir makinedir, bu yüzden erişimini kısıtlayın ve genel gezinmeden uzak tutun. Bakım maliyeti yamalanacak bir imaj daha demektir; bu gerçektir ama sınırlıdır ve görünürdür, dizüstü bilgisayarda unutulmuş bir LEGACY bayrağından farklı olarak.

Karşılaştırma size ne bırakır

Üç soruya göre seçin: eski protokol kime gerekiyor, ne kadar süre ve istisna gerekçesini aşarsa kim fark eder. Tek uygulama, tek kişi, birkaç gün süreç başına yapılandırmayı işaret eder. Tek cihazın arkasındaki bütün filo ağ geçidinin kendisini işaret eder. Ana makinede kalıcı LEGACY ilkesi gerektiren her şey, teknik kostüm giymiş bir satın alma kararıdır.

Kalıcı düzeltme cihaza aittir: TLS 1.2 veya daha yenisi, en az 2048 bitlik bir grup, bir AEAD şifresi ve modern imzalı bir sertifika. Bu değişikliği cihazın sahibinden isteyin, sonra istemci günlüğünde anlaşılan sürümü ve şifreyi doğrulayın. İstisnayı ana makine, ağ geçidi, anlaşılan protokol, onaylayan ve son kullanma tarihiyle birlikte yazın, çünkü geçici bir çözümün varsayılan olmasını engelleyen şey o nottur.