SECLEVEL=0 leczy objaw, a nie certyfikat

Połączenie OpenVPN zawodzi, ktoś znajduje jednolinijkową poprawkę dodającą SECLEVEL=0 i tunel wstaje. Nie zmienił się certyfikat ani zestaw szyfrów; przesunął się próg akceptacji w całej bibliotece, a wszystko, co proces robi później, dziedziczy nową granicę. Warto to zrozumieć, zanim ta sama linia zostanie skopiowana do każdego profilu w środowisku.

Ustal, która biblioteka i która polityka obowiązują

SECLEVEL to pojęcie OpenSSL, więc pierwsze pytanie brzmi, czy twoja kompilacja w ogóle używa OpenSSL. OpenVPN można połączyć z więcej niż jedną biblioteką kryptograficzną, a ustawienie dotyczące jednej z nich jest bez znaczenia dla pozostałych. Zapytaj plik binarny, z czym został zbudowany, a następnie zapytaj bibliotekę, którą wersję i konfigurację wczytała:

openvpn --version | head -3
openssl version -a

Czytaj uważnie wynik wersji, bo dystrybucje łatają wartości domyślne. Niektóre dostarczają konfigurację systemową, która podnosi poziom minimalny powyżej domyślnego upstreamu, i dlatego ten sam profil zachowuje się inaczej na dwóch maszynach z identycznymi pakietami OpenVPN. Obowiązująca polityka to ta wczytana przez działający proces, a nie ta z podręcznika upstreamu.

Następnie rozdziel dwie warstwy, które ludzie mylą. OpenVPN ma własne mechanizmy TLS, w tym ustawienie profilu certyfikatu i jawne listy szyfrów, i stoją one ponad wszystkim, co wymusza biblioteka. Obniżenie poziomu biblioteki nie zmienia tego, jakie szyfry wymienia twoja konfiguracja OpenVPN, a zawężenie listy OpenVPN nie podnosi progu biblioteki. Wiedza o tym, która warstwa cię odrzuciła, jest tym, co nie pozwala poprawce pozostać domysłem.

Rozdziel trzy rzeczy, które mogą zostać odrzucone

Pierwszy kandydat to materiał tożsamości: certyfikat, którego klucz jest za mały albo którego algorytm podpisu nie jest już akceptowany przez politykę. Drugi to parametr wymiany kluczy, na przykład grupa, którą polityka uznaje za zbyt słabą. Trzeci to zestaw szyfrów, który polityka wyklucza. Wszystkie trzy mogą spowodować błąd uścisku dłoni, a rozróżnia je tylko tekst błędu i etap negocjacji.

Żaden z tych trzech nie jest szyfrem kanału danych. OpenVPN negocjuje szyfrowanie tunelu osobno od uścisku dłoni TLS, więc połączenie, które udaje się po zmianie poziomu bezpieczeństwa, nic nie mówi o tym, który szyfr chroni twoje dane. Jeśli pytanie, które naprawdę zadajesz, dotyczy poufności danych, patrzysz na całkowicie niewłaściwe pokrętło.

Obniżenie poziomu poszerza akceptację wszystkich trzech danych wejściowych naraz. To jest część, którą ludzie pomijają: poprawka, która wpuszcza stary certyfikat, wpuszcza też słabą grupę i zestaw, którego być może nie zamierzałeś dopuszczać. Jedna usterka wywołała zmianę, a zmiana jest szersza niż usterka. Ta asymetria jest powodem, dla którego ograniczony wyjątek jest lepszy niż domyślne ustawienie dla całego środowiska.

Zmień dane wejściowe, a nie próg

Zachowaj dokładny błąd, zanim dotkniesz konfiguracji, w tym etap, który go zgłosił, i obiekt, który nazwał. Problem z certyfikatem rozwiązuje się, zastępując certyfikat czymś, co akceptuje bieżąca polityka, co zwykle oznacza ponowne wydanie go w urzędzie, a nie ponowną instalację tego samego pliku.

Jeśli odrzucone dane wejściowe należą do peera, którego nie kontrolujesz, rozmowa toczy się z jego właścicielem o obsługiwanym materiale zastępczym. Obniżenie własnego progu, by pomieścić system, którego nikt nie utrzymuje, przenosi koszt z nich na wszystkich, którzy łączą się po nich.

Tam, gdzie serwer egzekwuje politykę, sprawdź, czy prawdziwą przyczyną nie jest ustawienie na poziomie OpenVPN, zanim obwinisz bibliotekę. Profil certyfikatu wymagający surowszej klasy, niż może spełnić wdrożony certyfikat, zawiedzie niezależnie od poziomu bezpieczeństwa, a usunięcie tego profilu to węższa zmiana niż wyłączenie kontroli biblioteki.

Jeśli musisz go obniżyć, ogranicz i udokumentuj

Czasem zatwierdzony wyjątek zgodności jest właściwą odpowiedzią, zwłaszcza dla starego peera z datowanym planem wycofania. Ogranicz go do usługi, która go potrzebuje, a nie do całego hosta: plik konfiguracji dla konkretnej usługi lub dedykowana konfiguracja OpenSSL ma mniejszy promień rażenia niż eksport w profilu globalnym.

Zapisz razem z wyjątkiem cztery rzeczy: dokładne ustawienie, właściciela, który go zatwierdził, klientów, których dotyczy, oraz warunek, pod którym zostanie usunięty. Wyjątek bez warunku wycofania to trwałe osłabienie z dołączonym tymczasowym uzasadnieniem.

Wycofanie powinno być jednym krokiem, który już przetestowałeś. Zachowaj poprzednią konfigurację, zastosuj zmianę, potwierdź, że usługa się uruchamia, i dokładnie wiedz, który plik przywrócić, jeśli następne połączenie zachowa się inaczej niż oczekiwano.

Następnie zweryfikuj tożsamość i ochronę

Udane połączenie dowodzi tylko, że zmienione warunki je dopuściły. Potwierdź, że weryfikacja nazwy hosta i peera nadal wykonuje swoją pracę, że używany certyfikat to ten, który zamierzałeś wdrożyć, i że wynegocjowany kanał danych odpowiada polityce, którą, jak sądzisz, masz.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

Dokumentacja poziomów bezpieczeństwa OpenSSL wyraźnie stwierdza, że framework stosuje limity do kluczy, podpisów, grup i zestawów łącznie oraz że poziom zero pozwala na wszystko, co sprawdza wywołanie zwrotne. Taki jest zakres tego, co zmieniłeś, i to jest zdanie, które się cytuje, gdy ktoś pyta, czy poprawka była wąska.

Przekazanie, które przetrwa audyt, mówi, która polityka odrzuciła które dane wejściowe, co zmieniono i co w rezultacie pozostaje akceptowane. „To działa z SECLEVEL=0“ to obserwacja o jednym połączeniu, a nie ocena bezpieczeństwa wdrożenia.