Jeden stary peer wymusza TLS 1.0: ogranicz wyjątek, nie cały host

Pojawia się jedno stare urządzenie, nie potrafi się połączyć, a najszybsza z pozoru naprawa to osłabienie całego hosta, aż połączenie się uda. Ta wymiana jest niewidoczna w danej chwili i trwała w praktyce, bo nikt nie usuwa progu, który w końcu działa. Presję tworzą dwa bardzo różne błędy i tylko jeden z nich w ogóle dotyczy szyfrów. Najpierw posortuj błąd, potem umieść wyjątek tam, gdzie nie może się rozprzestrzenić.

Podziel awarię na dwie części, zanim zmienisz dyrektywę

Linia logu serwera o braku wspólnego szyfru albo o nieobsługiwanej wersji protokołu pochodzi z kanału kontrolnego: obie strony nie potrafiły uzgodnić, jak chronić same negocjacje. Linia klienta o tym, że nie włączono żadnej metody weryfikacji certyfikatu serwera, pochodzi z zupełnie innego miejsca, bo ten klient w ogóle nie sprawdza, kto odpowiedział. Zmiana szyfru danych nic nie daje w drugim przypadku, a dodanie sprawdzenia roli nic nie daje w pierwszym.

Weź najwcześniejszą nieudaną linię z każdej strony, a nie ostatnią przed rozłączeniem, bo ostatnia jest zwykle skutkiem. Następnie ustal, który plik klient naprawdę otworzył: zaimportowany profil często istnieje dwa razy pod różnymi nazwami wyświetlanymi, a edycja kopii, której nikt nie czyta, daje przekonujący brak zmiany. Działający proces zachowuje ustawienia, z którymi wystartował, więc zapisany plik to nie wczytany plik. Poniższe polecenia pokazują negocjacje klienta obok widoku serwera dla tej samej próby.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Drugi listener to uczciwe miejsce na słabszy próg

Gdy urządzenie zatrzymuje się na TLS 1.0 z kanałem danych sprzed 2.5, serwer musi zaproponować niższy próg kanału kontrolnego i szyfr danych rozpoznawany przez starego klienta. Dyrektywa fallback istnieje dokładnie dla tego peera, a lista szyfrów trzyma nowoczesnych klientów na nowoczesnych zestawach. Obie dyrektywy należą do listenera, a nie do użytkownika czy połączenia, i żadna opcja dla pojedynczego klienta ich później nie zawęża. Dlatego jedno starsze urządzenie na głównym porcie to decyzja o każdym peerze, który dzieli ten port.

Gdzie platforma na to pozwala, uruchom starszy listener jako osobną instancję na osobnym porcie, zezwól na ten port tylko z adresu urządzenia i zostaw główną usługę w spokoju. Zapisz, dlaczego drugi listener istnieje, w pliku, który zawiera jego konfigurację, bo inaczej przyszłe porządki odczytają go jako pozostałość. Rozdzielenie ma sens tylko wtedy, gdy słabszy próg kończy się tam, gdzie kończy się urządzenie.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Co naprawdę psuje stary certyfikat dostawcy

Błąd weryfikacji to brakujące powiązanie roli: bez niego klient zaakceptuje każdy certyfikat łańcuchowo prowadzący do zaufanego CA, niezależnie od tego, czy został wydany dla serwera. Najpierw powiąż certyfikat z rolą serwera i traktuj powiązanie jako wymóg, a nie pokrętło do dostrajania. Tylko profil, który nadal zawodzi po tym kroku, ma prawdziwy problem z certyfikatem.

Stary certyfikat dostawcy, którego rozmiar klucza lub algorytm podpisu nie spełnia już domyślnej polityki OpenSSL, to przypadek ograniczonej zmiany poziomu bezpieczeństwa na kanale kontrolnym. Obniżenie poziomu tam nie wyłącza weryfikacji i nigdy nie wolno go łączyć z pustym CA, wyłączoną weryfikacją ani niesprawdzoną nazwą hosta. Trzymaj tę linię w jednym profilu, który jej potrzebuje; wyeksportowanie złagodzonej konfiguracji OpenSSL globalnie dałoby to samo złagodzenie każdemu programowi na maszynie.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Czytaj wynegocjowane wartości, nie baner

Przy verbosity 4 obie strony wypisują uzgodnioną wersję TLS i szyfr kanału kontrolnego oraz szyfr danych sesji. Czytaj te linie, a nie baner inicjalizacji, który informuje o sukcesie, a nie o jego warunkach. Potem połącz ponownie nowoczesnego klienta z głównym listenerem i potwierdź, że nadal trafia na nowoczesny zestaw, bo wyjątek, który wyciekł do współdzielonej konfiguracji, ujawnia się tutaj najpierw. Wartości, które skopiujesz, stają się podstawą następnego przeglądu.

Przetestuj stare urządzenie osobno: powinno się połączyć i powinno być jedyną sesją w logach pokazującą słabsze parametry. Jeśli drugi peer też negocjuje stary zestaw, wyjątek jest szerszy niż zamierzano i rozdzielenie listenerów naprawdę nie nastąpiło. Zapisz obie obserwacje, a nie tylko wniosek.

Każdy wyjątek potrzebuje właściciela i daty

Wyjątek bez warunku usunięcia po cichu staje się domyślny, więc umieść urządzenie, właściciela, powód i datę, w której zniknie, obok konfiguracji, którą uzasadnia. Bez tej linii słabszy próg przeżyje sprzęt, który go wymagał.

Zastąpienie klienta albo poproszenie dostawcy o aktualny profil to wynik, do którego należy dążyć; wyjątek jest opóźnieniem, a nie projektem. Gdy urządzenie przechodzi na emeryturę, usuń listener i profil w tej samej zmianie, żeby żadna połowa nie działała dalej. Nic z tego nie czyni starych parametrów bezpiecznymi, po prostu nie pozwala, by limit jednego urządzenia stał się podstawą wszystkich.