Samopodpisany certyfikat VPN: co oznacza i czemu ufa

Najwięcej szkody robią tu dwa przekonania: że samopodpisany certyfikat VPN oznacza, iż tunel nie jest szyfrowany, oraz że instalowanie wszystkiego, o co poprosił klient VPN, dotyczy tylko VPN. Żadne nie przetrwa kontaktu z prawdziwym wdrożeniem. Samopodpisany certyfikat opisuje relację podpisu, a nie wyrok bezpieczeństwa, a zasięg dodawanego zaufania zależy od tego, do którego magazynu trafi. Widziałem, jak helpdesk importował główny certyfikat dostawcy do maszyny z Windows, żeby uciszyć jedno ostrzeżenie, a potem spędził popołudnie na wyjaśnianiu, dlaczego przeglądarka przestała skarżyć się na niezwiązany portal. Obie połowy tego pytania należą do siebie, więc traktuj je jako jedno.

Certyfikat to nie magazyn zaufania

Plik przedstawiany przez serwer zawiera klucz publiczny, nazwę podmiotu, nazwę wystawcy, daty ważności i rozszerzenia. Samopodpisany oznacza, że podmiot i wystawca to ta sama jednostka, a podpis weryfikuje się własnym kluczem certyfikatu. Nic w tej definicji nie mówi, że połączenie jest słabe, ani nic nie mówi, że klient je zaakceptuje.

Akceptacja przychodzi skądinąd: plik CA, na który wskazujesz klienta, odcisk palca porównywany ręcznie albo korzeń, który już leży w magazynie czytanym przez klienta. Wdrożenie może być całkowicie zdrowe, choć jego certyfikat oblałby każdy publiczny test. openssl verify wobec pakietu systemowego zgłosi nieznanego wystawcę, a ten raport jest poprawny, nie jest usterką.

Opcja ca OpenVPN to najjaśniejszy przypadek zaufania ograniczonego do aplikacji. Ten plik nazywa kotwice, które klient zaakceptuje, i może zawierać jeden prywatny CA albo w małym wdrożeniu własny samopodpisany certyfikat serwera. Wersja 2.6 przyjmuje też --peer-fingerprint do przypinania odcisku SHA-256 zamiast dystrybuowania pliku CA. WireGuard stoi jeszcze dalej: nie ma żadnych certyfikatów, tylko statyczny klucz publiczny na każdego peera, więc pytanie o samopodpisanie do niego nie pasuje.

To, gdzie instalujesz zaufanie, decyduje, kto je odziedziczy

Umieść ten sam certyfikat w trzech miejscach, a dostaniesz trzy różne promienie rażenia. Pakiet czytany tylko przez klienta VPN wpływa na tego klienta. Korzeń w magazynie systemu operacyjnego wpływa na każdy program, który konsultuje ten magazyn. Przeglądarka z własną bazą zaufania może ignorować oba, dlatego ostrzeżenie może przetrwać import, który wyglądał na udany.

W Debianie lub Ubuntu umieszczenie pliku w /usr/local/share/ca-certificates/ i uruchomienie update-ca-certificates zmienia pakiet ogólnosystemowy. W Windows certutil -addstore -f Root zapisuje do magazynu maszyny i wymaga podniesionego wiersza poleceń, natomiast dodanie -user celuje w magazyn bieżącego użytkownika; te dwa nie są wymienne. Firefox trzyma własną bazę NSS, więc import na poziomie systemu może nigdy się tam nie pojawić.

Zasięg ma znaczenie z powodu tego, co może zrobić organ. Wystawiający CA może podpisywać nazwy, z którymi nie ma żadnego związku, więc wszystko, co ufa temu magazynowi, zaakceptuje te podpisy. Pojedynczy przypięty liść tego nie potrafi; uwierzytelnia dokładnie jedną tożsamość peera. Jeśli celem jest połączenie jednego VPN, CA ograniczony do aplikacji lub przypięty liść to osiąga, podczas gdy korzeń na całą maszynę jest o wiele większą koncesją, niż wymaga objaw.

Nadal szyfrujesz bez publicznego CA

Uścisk dłoni TLS wyprowadza klucze sesji niezależnie od tego, czy certyfikat peera łączy się łańcuchem z czymś, czemu już ufasz. Samopodpisany nie oznacza zwykłego tekstu ani tego, że ruch jest czytelny w locie. Oznacza, że klient nie ma z góry powodu wierzyć, że klucz należy do serwera, o który prosił.

W tej luce żyją prawdziwe ataki. Klient skonfigurowany do akceptowania dowolnego certyfikatu, czy to przez wyłączone ustawienie weryfikacji, czy przez przycisk „zaufaj mimo to” kliknięty raz i zapomniany, będzie chętnie szyfrował do każdego, kto odpowie. Przechwycenie następuje na etapie uwierzytelniania, zanim dane aplikacji się poruszą. Szyfrowanie bez sprawdzenia tożsamości trzyma pasywnego obserwatora z dala i robi niewiele więcej.

Zaufanie do wystawcy nie pomija sprawdzenia nazwy

Walidacja łańcucha, dopasowanie nazwy i przeznaczenie certyfikatu to osobne decyzje. Łańcuch może być ważny, gdy nazwa jest błędna, a nazwa może pasować, gdy certyfikat wydano do innej roli. RFC 5280 definiuje pola, które niosą te ograniczenia, a to, jak ściśle klient je egzekwuje, jest sprawą każdej aplikacji.

OpenVPN czyni podział widocznym. verify-x509-name przypina oczekiwany podmiot przez dopasowanie name, name-prefix lub subject. remote-cert-tls server wymaga, by certyfikat peera był użyteczny jako certyfikat serwera, co odrzuca certyfikat tylko klienta, nawet gdy wystawca jest zaufany. Żadne z tych ustawień nie jest zastępowane wysłaniem pliku CA.

Sprawdź certyfikat, zanim cokolwiek postanowisz:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName pokazuje, kto go wydał, dla jakich nazw i do kiedy.
• openssl verify -CAfile ca.crt server.crt sprawdza, czy łańcuch, który zamierzasz wysłać, naprawdę waliduje liść.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error działa dla punktów końcowych TLS, takich jak portal WWW; protokół OpenVPN na porcie 1194 nie jest zwykłym strumieniem TLS, więc ten test tam nie obowiązuje.

Certyfikat z wygasłą datą, bez subjectAltName dla nazwy, z którą się łączysz, lub bez użycia serverAuth zawodzi niezależnie od tego, jak starannie zainstalowano kotwicę.

Pięć kontroli, zanim go zaakceptujesz

Porównaj odcisk palca kanałem, który nie jest połączeniem, które próbujesz naprawić: konsolą, instalatorem, który już masz, podpisanym plikiem konfiguracji. openssl x509 -in server.crt -noout -fingerprint -sha256 na serwerze i ta sama wartość w logu klienta wystarczą, by wiedzieć, że patrzysz na jeden obiekt.

Następnie zdecyduj, co instalujesz: jeden liść czy organ, który może wybić więcej. Potem zdecyduj, dokąd to trafia, i nazwij aplikacje czytające ten magazyn. Zapisz ścieżkę usunięcia, póki jeszcze ją pamiętasz, bo zaufaj-i-idź-dalej to sposób, w jaki tymczasowy import staje się trwały.

Na koniec zaplanuj zmianę. Przypięty certyfikat lub odcisk palca trzeba aktualizować tym samym zaufanym kanałem, gdy certyfikat się rotuje, a prywatny CA ma własny cykl wydawania i unieważniania. Jeśli klucz prywatny wycieknie, ponowne zaufanie kopii tego samego certyfikatu niczego nie naprawia; tożsamość trzeba wymienić.

Jeśli ostrzeżenie przetrwa wszystkie pięć kontroli, użyteczne pytanie nie brzmi, który przycisk je ucisza, ale który magazyn klient faktycznie czyta i skąd wziął się ten korzeń. Odpowiedz na to, a import, który zamierzasz wykonać, stanie się decyzją zamiast odruchem.