Błąd szyfru TLS w OpenVPN: najpierw porównaj obie strony

Błąd „brak wspólnego szyfru“ brzmi jak jedno ustawienie do zmiany, a ustawienie, które zmienia większość, jest niewłaściwe. OpenVPN trzyma osobne zasady dla kanału kontrolnego, który wykonuje uścisk dłoni TLS, i dla kanału danych, który przenosi pakiety wewnątrz tunelu, a błąd nazywa pierwszy, podczas gdy ludzie edytują drugi. Porównanie tego, co dopuszcza każda strona, we właściwej kolejności, zamienia zgadywanie w dwie lub trzy decyzje: wersja, potem lista zestawów, potem poświadczenia.

Pomyli się w tej kolejności i można stracić godzinę, dodając nazwę AES do listy, która nigdy nie była sprawdzana.

Dwie listy szyfrów, a tylko jedna psuje uścisk dłoni

Kanał kontrolny negocjuje sesję TLS, a jego zasady zapisuje się za pomocą tls-cipher dla TLS 1.2 i tls-ciphersuites dla TLS 1.3. Kanał danych konfiguruje się osobno za pomocą data-ciphers, gdzie niezgodność daje połączenie, które się zestawia, a potem nie przepuszcza ruchu. Oba dają błędy wspominające szyfry, dlatego są mylone. Uścisk dłoni, który nigdy się nie kończy, wskazuje kanał kontrolny, natomiast zestawiony tunel, który gubi pakiety, wskazuje kanał danych.

Czytaj całą wiadomość, a nie pierwszy wiersz. Niezgodność wersji, brakujący zestaw, algorytm podpisu certyfikatu odrzucany przez stronę i nieudana weryfikacja nazwy hosta kończą się błędem TLS, a tylko jeden z nich dotyczy twojej listy zestawów. Rozdzielenie tych kategorii to większość diagnozy.

Porównaj wersje, zanim porównasz zestawy

Strona ograniczona do TLS 1.2 i strona wymagająca 1.3 nie dzielą żadnej wersji i żaden ciąg szyfru tego nie łączy. Zapisz tls-version-min i tls-version-max po obu stronach albo wartości domyślne używanych kompilacji, ponieważ zasady OpenSSL w dystrybucji mogą podnieść dolny limit, choć żadna opcja OpenVPN tego nie mówi. Jeśli jedna strona to urządzenie lub klient innej firmy, jej okno to to, na co pozwala firmware. Dopiero gdy okna się nakładają, porównanie zestawów coś znaczy.

Te zapisy powinny też nazywać rzeczywiste pliki binarne. Wiersz poleceń openvpn na twoim laptopie niekoniecznie jest klientem, który obsługuje zaimportowany profil.

Listy TLS 1.2 i TLS 1.3 się nie mieszają

Nazwy zestawów TLS 1.2 wyglądają tak: ECDHE-RSA-AES256-GCM-SHA384 i należą do tls-cipher, który przyjmuje ciąg szyfru OpenSSL. Zestawy TLS 1.3 nazywają się TLS_AES_256_GCM_SHA384 i należą do tls-ciphersuites; dodanie jednego do ciągu 1.2 nie konfiguruje listy 1.3, a parser może przyjąć tekst, nigdy go nie dopasowując. Filtr poprawny dla jednej wersji nic nie mówi o drugiej. Zapisz, dla której wersji jest każda lista.

openvpn --show-tls wypisuje, co obsługuje lokalna kompilacja, a to inwentarz, nie obietnica: zdalna strona może nie dopuszczać tych zestawów, a aktywny profil może ich nie włączać. Użyj go, by wykluczyć kompilację, która w ogóle nie może zaoferować zestawu, a potem porównaj skonfigurowane listy.

Udowodnij negocjację na nowym połączeniu

Udany uścisk dłoni to jedyny dowód, który się liczy, i musi pochodzić z prawdziwego klienta z prawdziwym profilem. Zwiększ szczegółowość serwera, połącz się raz i odczytaj z logu wynegocjowaną wersję protokołu oraz zestaw, zamiast zakładać, że wygrała pierwsza zaproponowana wartość. Potem potwierdź kanał danych osobno ruchem przez tunel, bo działający uścisk dłoni i zawodzący kanał danych to różne naprawy. Powtarzaj po każdej zmianie konfiguracji, bo nieaktualny profil klienta to częsty wynik fałszywie negatywny.

Jeśli nie istnieje zatwierdzona wspólna konfiguracja, odpowiedzią jest aktualizacja lub plan migracji, a nie osłabiona polityka. tls-version-min obniżenie, wyłączenie weryfikacji lub włączenie wszystkich starych zestawów usuwa odrzucenie bez spełnienia wymogu bezpieczeństwa, który je wywołał.

Zapisz wynegocjowaną wersję, zestaw i szyfr danych w zgłoszeniu zmiany. Następna osoba, która napotka błąd TLS, zacznie od tego zapisu, a nie od ciągu szyfru znalezionego w poście na forum.