OpenVPN bez certyfikatu klienta: polityka serwera, nie profil

Usuwasz wiersze certyfikatu i klucza, przekazujesz profil, a połączenie nadal kończy się błędem certyfikatu. Profil nigdy nie był tym, co wymuszało ten wymóg. O tym, czy certyfikat klienta jest obowiązkowy, decyduje serwer, i żadna zmiana po stronie klienta tego nie wynegocjuje. Poprawką jest więc zmiana polityki serwera, dokonana świadomie, z wszystkim, co od niej zależy, zaktualizowanym w tym samym przebiegu.

Profil to nie polityka

Community OpenVPN 2.6 jest dostarczany z obowiązkowymi certyfikatami klienta, ponieważ verify-client-cert domyślnie przyjmuje wartość require. Ustawienie none zatrzymuje żądanie certyfikatu i przekazuje uwierzytelnianie klienta temu układowi nazwy użytkownika i hasła, który serwer już obsługuje. Starsze poradniki sięgają po client-cert-not-required, przestarzały zapis tej samej idei, więc użyj dyrektywy udokumentowanej w zainstalowanej wersji. W każdym razie zmiana zachodzi na serwerze i żaden profil klienta nie może jej wykonać.

Poniższy fragment to cała zmiana po stronie serwera i sam w sobie nie jest działającą konfiguracją uwierzytelniania. verify-client-cert none usuwa wymóg certyfikatu, natomiast username-as-common-name czyni nazwę konta tożsamością, którą widzą późniejsze wywołania zwrotne i pliki poszczególnych klientów. Żaden z wierszy nie sprawdza hasła, więc weryfikator nadal musi istnieć.

verify-client-cert none
username-as-common-name

Ten weryfikator to wtyczka lub skrypt sterowany przez auth-user-pass-verify, i musi być na miejscu, zanim którykolwiek z powyższych wierszy coś znaczy. Odwrócenie kolejności daje okno, w którym serwer nie żąda certyfikatu i nie sprawdza żadnego konta.

Co nadal weryfikuje serwer

Rezygnacja z certyfikatu klienta nie oznacza rezygnacji z TLS. Serwer zachowuje swój certyfikat i klucz, a klient zachowuje zaufanie do CA i kontrole nazwy hosta, które powstrzymują go przed rozmową z oszustem. Usuwanie remote-cert-tls server lub pakietu CA dlatego, że klient nie ma już certyfikatu, to częste i poważne błędne odczytanie, a dokumentacja 2.6 wyraźnie stwierdza, że oba kierunki są niezależne. Jeden dowodzi serwera klientowi; drugi dowodzi klienta serwerowi.

Profil może też zawierać blok tls-auth lub tls-crypt. To współdzielony klucz kanału sterowania z własnym cyklem dystrybucji i rotacji, więc plik bez wierszy certyfikatu i klucza nie jest automatycznie bezpieczny do publikacji. Traktuj go jak tajemnicę, dopóki go nie przeczytasz.

Plik certyfikatu skopiowany z działającego profilu sam niczego nie dowodzi; posiadanie oznacza trzymanie pasującego klucza prywatnego, co sprawdza wdrożenie uwierzytelniane certyfikatem. Plik zawierający certyfikat nie jest plikiem, którym można się uwierzytelnić.

Co musi robić weryfikator

Po usunięciu wymogu certyfikatu wszystko opiera się na weryfikatorze: wtyczce lub skrypcie sterowanym przez auth-user-pass-verify. Musi odrzucać nieprawidłowe dane logowania, odrzucać konta wyłączone lub niekwalifikujące się i zawieść w sposób zamknięty, gdy nie może dotrzeć do swojego backendu. username-as-common-name jest często włączany obok, i zmienia tożsamość, którą widzą późniejsze wywołania zwrotne i pliki konfiguracji poszczególnych klientów. Nie weryfikuje hasła i nie czyni niekwalifikującego się konta kwalifikującym. To osobne zadania, a ich mieszanie to sposób, w jaki migracja przechodzi test szczęśliwej ścieżki i zawodzi przy pierwszym prawdziwym incydencie.

Testuj przypadki negatywne tak samo starannie jak pozytywny. Profil, który pokazuje monit o hasło, dowodzi tylko, że klient potrafi narysować monit, natomiast serwer, który akceptuje błędne hasło, dowodzi czegoś znacznie gorszego. Dodaj do zestawu testów wyłączone konto i wygasłe dane logowania, nie tylko złe hasło.

Zmieniaj politykę, profil i mapowanie razem

Skoordynuj trzy rzeczy: dyrektywę serwera, profil klienta i mapowanie tożsamości poszczególnych klientów. Zmień je osobno, a klienci zawodzą przed weryfikacją lub łączą się pod nazwą, której administrator się nie spodziewał, co jest gorsze, bo wygląda jak sukces. Połączenie, które udaje się pod niewłaściwą tożsamością, trudniej zauważyć niż takie, które zawodzi.

Trzymaj dwa konta testowe dla tej ścieżki, jedno ważne i jedno znane jako złe, i używaj obu po każdej zmianie weryfikatora. Ważne konto dowodzi szczęśliwej ścieżki i mapowania tożsamości; złe dowodzi, że odrzucanie nadal działa. Żaden test nie mówi nic o regułach kwalifikowalności, więc dodaj konto, które powinno zostać odrzucone ze względów polityki, jeśli wdrożenie je ma. Uruchamiaj wszystkie trzy po każdej zmianie, ponieważ weryfikator, który zaczyna akceptować wszystko, wygląda dokładnie jak działające logowanie.

Zapisuj, jakie metody uwierzytelniania serwer faktycznie akceptuje, a nie jakie sugeruje profil. Ten zapis odpowiada na pytanie, które ludzie wciąż zadają, mianowicie kto może połączyć się z tą usługą. Przetrwa też kolejnego administratora, który w przeciwnym razie odkryłby go ponownie z przechwycenia pakietów.