OpenVPN tls-ciphersuites kontra tls-version-min: co wymusza każda z opcji

Trzy różne fakty są w większości dyskusji o OpenVPN i TLS spłaszczane do jednego wiersza: co potrafi twoja kompilacja klienta, na co pozwala profil i co sesja faktycznie wynegocjowała. Krótka lista zestawów TLS 1.3 odpowiada tylko w połowie na środkowe pytanie i nic nie mówi o dolnym progu wersji protokołu. Przejdź przez poniższe kontrole po kolei i zatrzymaj się na pierwszej, która nie wytrzymuje, bo każda kolejna zakłada, że poprzednie są załatwione.

Sprawdź kompilację, zanim przeczytasz jakąkolwiek listę

Dyrektywa konfiguracji nie może dodać obsługi protokołu do pliku binarnego, który jej nie ma. Zacznij od banera wersji, który podaje skompilowaną bibliotekę kryptograficzną:

openvpn --version

Kompilacja 2.6 połączona z OpenSSL akceptuje zarówno tls-cipher, jak i tls-ciphersuites. Kompilacja z mbed TLS nie ma w ogóle wyboru zestawów TLS 1.3, a podręcznik 2.6 oznacza tls-ciphersuites jako opcję OpenSSL. Jeśli serwer zostanie przebudowany z innym backendem, ten sam profil może zmienić zachowanie bez zmiany ani jednej linii konfiguracji.

Skoro już tu jesteś, uruchom openvpn --show-tls i zachowaj wynik. To inwentarz, z którym później porównasz, i tanio jest go przechwycić, zanim ktoś zacznie edytować profile.

Zapisz baner i listę w zgłoszeniu zmiany, a nie w oknie czatu. Kiedy dwie osoby spierają się, czy klient za sześć tygodni będzie mógł zaproponować zestaw, przechwycony wynik rozstrzyga to w jednej linii.

Trzymaj granice wersji osobno od list szyfrów

W podręczniku 2.6 to trzy mechanizmy, a nie jeden:

• tls-cipher ustawia politykę szyfrów dla TLS 1.2 i starszych i jest przekazywany do listy szyfrów OpenSSL;
• tls-ciphersuites wybiera zestawy TLS 1.3;
• tls-version-min i tls-version-max ograniczają wersje protokołu, których połączenie może używać.

Uważnie przycięta lista zestawów TLS 1.3 nie dowodzi więc niczego o tym, że starsza wersja jest nadal dozwolona. Jeśli wymaganiem jest «tylko TLS 1.3», to próg wersji go niesie, a lista zestawów jedynie zawęża wybory w obrębie tego progu:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Ta para wykonuje dwa zadania. Usunięcie jednej z linii sprawia, że druga wymusza mniej, niż myślisz, i właśnie tej awarii służy cała ta kontrola.

Kanał danych to czwarty mechanizm. data-ciphers negocjuje szyfr symetryczny wewnątrz tunelu, a jego wynik nic nie mówi o wersji TLS kanału sterującego. Widok AES-256-GCM w podsumowaniu sesji nie jest dowodem na TLS 1.3 w żadną stronę.

Czytaj show-tls jako lokalny inwentarz

--show-tls wylicza zestawy obsługiwane przez bibliotekę kryptograficzną, z którą połączony jest ten plik binarny, w kolejności preferencji. To nie jest raport z bramy. Podręcznik wprost mówi, że lista pochodzi z biblioteki lokalnej, co oznacza, że laptop z OpenSSL 3.x i router ze starszą kompilacją wydrukują różne listy, rozmawiając z tym samym serwerem.

Załóżmy, że klient obsługuje zestawy A, B i C, a jedna sesja wybiera B. To nie ustala niczego o tym, czy serwer pozwala na A lub C, ani o tym, czy B jest jego jedynym dozwolonym wyborem. Trzymaj trzy wiersze osobno, a większość mylących wątków o TLS rozwiąże się sama.

Inwentarz wciąż warto zachować. Gdy sesja zawodzi, porównanie listy biblioteki z listą profilu mówi, czy klient miał w ogóle szansę zaproponować to, czego chciał serwer. Pokazuje też, czy zmiana backendu po cichu usunęła TLS_CHACHA20_POLY1305_SHA256 z puli, na której polegają starsi klienci — rodzaj regresji, który objawia się jako garstka użytkowników niepotrafiących się połączyć, podczas gdy wszyscy inni niczego nie zauważają.

Zapytaj bramę o coś, na co potrafi odpowiedzieć

Jeśli administrujesz usługą, sprawdź efektywną konfigurację działającej instancji, a nie plik na dysku. OpenVPN mógł zostać uruchomiony z inną ścieżką --config, może pobierać dołączenia i może nie zostać zrestartowany od czasu edycji. Klienci spotykają politykę działającego demona.

Jeśli nie administrujesz, poproś operatora o obsługiwane wymagania klienta albo ograniczony test akceptacyjny. Odrzucona próba nie jest automatycznie odrzuconym zestawem: próg wersji, kontrole tożsamości certyfikatu, takie jak remote-cert-tls, lub niezgodność tls-auth i tls-crypt mogą zakończyć wymianę, zanim wybór zestawu zacznie mieć znaczenie. Przeczytaj błąd serwera, zanim zmienisz listę klienta, ponieważ „handshake failed” obejmuje cztery różne przyczyny i tylko jedna z nich to niezgodność szyfru.

Wskazanie openssl s_client na port VPN też nie odtwarza pytania. Kanał sterujący działa wewnątrz własnej ramki OpenVPN, więc surowa sonda TLS testuje inny protokół na porcie, który oczekuje czegoś innego. Każdy wniosek z niej dotyczy sondy, a nie tunelu.

Zapisz dwa wyniki i trzymaj je osobno

Świeża dozwolona sesja tworzy wiersz kanału sterującego z wersją protokołu i wybranym szyfrem oraz osobny wiersz kanału danych z szyfrem tunelu. Przechwyć oba razem z wersją klienta i nazwą profilu, i zanotuj, która instancja serwera odpowiedziała:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Potem odczytaj te dwa wiersze z tego pliku, a nie z pamięci. Para jest dowodem; sama nazwa zestawu to preferencja, a granica wersji to osobne stwierdzenie o tym, czego serwer odmawia.

Wykonaj kontrole w tej kolejności. Potwierdź kompilację i backend za pomocą --version. Przechwyć --show-tls, zanim cokolwiek zmienisz. Podaj wymagany próg wersji osobno od listy zestawów. Potwierdź efektywną politykę działającej instancji z jej właścicielem. Obserwuj jedną dozwoloną sesję i, jeśli plan na to pozwala, jedną odrzuconą próbę ze starszą wersją. Zapisz wyniki kanału sterującego i kanału danych jako osobne ustalenia.

Jeśli wymagany klient nie może spełnić nowego minimum, podejmij tę decyzję o migracji lub wyjątku jawnie, zamiast po cichu obniżać niepowiązaną regułę akceptacji, żeby wdrożenie wyglądało na zakończone.