Nieprawidłowa wersja TLS w AnyConnect na Linuksie: najpierw określ zakres poprawki

Ten błąd pojawia się przed monitem o hasło i to jest użyteczna część: nic jeszcze nie zostało uwierzytelnione, więc problemem nie są dane logowania. W Linuksie ten sam komunikat AnyConnect może pochodzić ze starej wersji protokołu, z 1024-bitowej grupy wymiany kluczy albo z zestawu szyfrów, którego polityka kryptograficzna systemu nie akceptuje. Usunąłem go na trzy różne sposoby na trzech maszynach i tym, co odróżnia te poprawki, jest zasięg, a nie pomysłowość. Każda jest uzasadniona we właściwym miejscu i złą wartością domyślną wszędzie indziej.

Przeczytaj komunikat, zanim dotkniesz polityki

Zapisz dokładny ciąg z okna dialogowego. Skarga na wersję wskazuje warstwę protokołu, skarga na certyfikat wskazuje zaufanie lub nazewnictwo, a nieudane logowanie wskazuje dane uwierzytelniające. Brama oferująca TLS 1.0 z 1024-bitową grupą DHE, AES-256-CBC i podpisem SHA-1 może mieć całkowicie ważny certyfikat i mimo to zostać odrzucona przez nowoczesną politykę, zanim Twoje dane zostaną w ogóle wysłane.

Sprawdź punkt końcowy systemowym OpenSSL, używając prawdziwej nazwy hosta i portu, którego używa klient.

Gdy openssl s_client -connect vpn.example.com:443 -servername vpn.example.com zawodzi, a -tls1 -cipher DEFAULT@SECLEVEL=0 się udaje, granicą jest wersja i rozmiar klucza razem. Jeśli pierwsze polecenie zgłasza mały klucz DH zamiast alertu protokołu, wersja jest w porządku i uwagi wymaga tylko grupa. Nigdy nie wkładaj do sprawdzenia klucza prywatnego ani hasła.

Opcja 1: poluzuj cały host polityką kryptograficzną

W Fedorze oraz RHEL 8 i 9 update-crypto-policies --set LEGACY obniża politykę systemową OpenSSL, a update-crypto-policies --show potwierdza, co jest aktywne. Zwykle przywraca to tunel, ale polityka jest czytana przy starcie procesu, więc przed ponownym testem uruchom ponownie klienta i każdy proces pomocniczy, który utworzył. Pozwala też na starsze protokoły i słabsze grupy dla każdego klienta TLS na maszynie, od przeglądarki w sąsiednim oknie po menedżera pakietów aktualizującego jądro.

Ta szerokość jest całym celem i całym problemem. LEGACY obowiązuje dla całego hosta, jest trwała i łatwa do zapomnienia, więc powinna być krokiem diagnostycznym albo udokumentowanym wyjątkiem w zarządzanej instalacji, nigdy stanem spoczynku stacji roboczej. Widziałem jedną, która została na LEGACY przez dwa lata, bo potrzebował jej jeden wewnętrzny portal, i nikt nie potrafił powiedzieć, kiedy to się zaczęło.

Debian i Ubuntu nie mają na to jednego przełącznika. Odpowiednikiem jest zmiana w /etc/ssl/openssl.cnf, która ustawia niższy MinProtocol i CipherString = DEFAULT@SECLEVEL=0 w sekcji domyślnych ustawień systemu. Ten sam zasięg, inny plik, nieco łatwiej zgubić go z oczu podczas aktualizacji wydania.

Opcja 2: jeden plik konfiguracyjny dla jednego klienta

Konfiguracja OpenSSL na proces trzyma zmianę w jednym drzewie procesów, ale tylko wtedy, gdy plik jest podłączony tak, jak oczekuje biblioteka. Nazwanie sekcji ssl_conf nie wystarczy: OpenSSL czyta klucz najwyższego poziomu openssl_conf, podąża za nim do sekcji inicjalizacji i dopiero wtedy dociera do ustawień domyślnych 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

Wskaż OPENSSL_CONF na ten plik i uruchom klienta VPN przez nakładkę, która go eksportuje. Wszystko inne na hoście zachowuje politykę domyślną i to jest ta właściwość, która ma znaczenie, gdy pojawia się pytanie o zgodność. Potwierdź, że plik naprawdę działa, zanim obwinnisz bramę: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 powinno wymienić szyfry TLS 1.0, a pusty wynik oznacza, że łańcuch jest przerwany i klient po cichu zachował ustawienia systemowe.

Plik jest wrażliwy na wersję. OpenSSL 1.1.1 i 3.x akceptują te same nazwy sekcji, ale obsługa dyrektyw wokół dostawców zmieniła się w 3.x, więc weryfikuj za pomocą logu samego klienta i próbnego uścisku dłoni, zamiast zakładać, że plik został odczytany. Literówka w nazwie sekcji kończy się niepowodzeniem otwartym, a klient po cichu używa ustawień systemowych.

Ograniczeniem jest pokrycie. Wszystko, co jest zlinkowane z GnuTLS lub NSS, ignoruje OPENSSL_CONF, podobnie jak każdy proces pomocniczy uruchamiany przez klienta bez odziedziczonego środowiska. Sprawdź za pomocą ldd, z którą biblioteką TLS plik binarny jest naprawdę zlinkowany, zanim zbudujesz nakładkę, bo odpowiedź decyduje, czy ta opcja w ogóle istnieje.

Opcja 3: jednorazowa maszyna wirtualna lub kontener

Dla wykonawcy, który przez dwa tygodnie atakuje jedną starą bramę, dedykowana maszyna wirtualna z poluzowaną polityką jest czystszą granicą niż stacja robocza. Stara powierzchnia i codzienny profil przeglądarki przestają dzielić politykę jądra, a utylizacja jest usunięciem, nie ustaleniem audytu.

To wciąż maszyna w sieci, więc ogranicz do niej dostęp i trzymaj ją z dala od ogólnego przeglądania. Koszt utrzymania to kolejny obraz do załatania, co jest realne, ale ograniczone i widoczne, w przeciwieństwie do zapomnianej flagi LEGACY na laptopie.

Co daje Ci to porównanie

Wybieraj na podstawie trzech pytań: kto potrzebuje starego protokołu, jak długo i kto zauważy, jeśli wyjątek przeżyje swój powód. Jedna aplikacja, jedna osoba, kilka dni wskazują na konfigurację na proces. Cała flota za jednym urządzeniem wskazuje na samą bramę. Wszystko, co wymaga stałej polityki LEGACY na hoście, jest decyzją zakupową w technicznym kostiumie.

Trwała poprawka należy do urządzenia: TLS 1.2 lub nowszy, grupa co najmniej 2048 bitów, szyfr AEAD i certyfikat z nowoczesnym podpisem. Poproś właściciela urządzenia o tę zmianę, a potem potwierdź wynegocjowaną wersję i szyfr w logu klienta. Zapisz wyjątek razem z hostem, bramą, wynegocjowanym protokołem, osobą zatwierdzającą i datą wygaśnięcia, bo to właśnie notatka powstrzymuje tymczasowe obejście przed staniem się domyślnym.