OpenVPN bez CA: jak peer-fingerprint weryfikuje partnerów

Małe wdrożenie sięga po odciski palców, bo urząd certyfikacji wygląda jak infrastruktura, na którą nikt nie ma czasu. Instynkt jest rozsądny, ale skrót, który ludzie wybierają zamiast tego—kopiowanie jednego sekretu kanału danych na oba końce—nie jest. Konfiguracja peer-fingerprint zachowuje strukturę TLS nietkniętą: każda strona nadal ma własny klucz prywatny i certyfikat, i każda strona nadal weryfikuje drugą. Zmienia się to, gdzie weryfikacja jest zakotwiczona: od zaufanego wystawcy do krótkiej listy przypiętych skrótów. Ponieważ skrót obejmuje cały certyfikat, a nie nazwę, odnowienie staje się operacją, która naprawdę zajmuje czas.

Do czego odcisk naprawdę się zobowiązuje

Odcisk certyfikatu to skrót całego certyfikatu zakodowanego w DER, a nie jego klucza publicznego i nie nazwy podmiotu. Dlatego dwa certyfikaty o identycznych nazwach i tym samym kluczu, ale różnych datach ważności mają różne odciski. To czyni przypinanie precyzyjnym, a zarazem czyni odnowienie uciążliwym. Przypięcie nie może oznaczać zaufania do klucza w ogóle, bo nazywa jeden artefakt w jednym momencie jego życia. Każdy może znać skrót, a sama jego znajomość niczego nie dowodzi.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Posiadanie pasującego klucza prywatnego jest tym, co dowodzi, że partner ma ten certyfikat, a skrót jest sposobem, w jaki druga strona decyduje, czy w ogóle oczekiwała tego certyfikatu. Ten rozdział jest powodem, dla którego ten projekt nie jest starą umową ze wspólnym sekretem: wspólny klucz uwierzytelnia każdego, kto zna te same bajty, podczas gdy przypięcie uwierzytelnia jeden certyfikat. Inne urządzenie dostaje własny wpis zamiast kopii tego samego sekretu, co jest małą różnicą w plikach i dużą w zasięgu szkód.

Mapa jest wzajemna, a nie symetryczna

Każdy punkt końcowy potrzebuje dwóch rzeczy: własnego klucza prywatnego z certyfikatem oraz deklaracji, które certyfikaty partnerów zaakceptuje. U klienta tą deklaracją jest skrót certyfikatu serwera; u serwera jest to lista skrótów zarejestrowanych klientów. Oficjalny przykład dla małej konfiguracji dla Community 2.6 pokazuje układ z peer-fingerprint, i warto go przeczytać, zanim wybierzesz ten model zaufania do rzeczywistego wdrożenia. Dwa kierunki nie są jedną odwróconą listą i nie zawodzą w tym samym momencie.

Dodanie urządzenia edytuje listę dozwolonych na serwerze, bez kopiowania prywatnego materiału istniejącego klienta i bez przenoszenia klucza serwera gdziekolwiek. Oba kierunki zawodzą też niezależnie, co jest przydatne przy diagnozie: strona, która zamyka uścisk dłoni, to strona, której oczekiwanie nie zostało spełnione. Jeśli klient odrzuca serwer, skrót nie zgadza się z przedstawionym certyfikatem. Jeśli serwer odrzuca klienta, skrót tego klienta brakuje na liście albo klient przedstawia certyfikat inny niż zarejestrowany.

Rejestracja: jak dołącza nowe urządzenie

Wygeneruj klucz i certyfikat nowego urządzenia tam, gdzie będzie mieszkał klucz prywatny, a następnie przenieś tylko publiczny artefakt do strony, która ma go przypiąć. Przekaż oczekiwany skrót kanałem, któremu już ufasz, i porównaj cały certyfikat, a nie znajomo wyglądającą nazwę. Skrót skopiowany z tego samego niezweryfikowanego pobrania co certyfikat dowodzi tylko, że oba pliki zgadzają się ze sobą. To kontrola spójności, a nie tożsamości, i to najcichszy sposób, w jaki ten projekt słabnie.

Na serwerze dodanie skrótu to zmiana konfiguracji, która przechodzi przez zwykłego menedżera i jest po niej ponowne połączenie. Potwierdź, że nowe urządzenie się łączy, a urządzenie, którego skrót usunięto, już nie. Test obejmujący tylko przypadek pozytywny pozostawia listę dozwolonych niezweryfikowaną, i dokładnie w takim stanie będziesz za pół roku.

Odnowienie to drogi moment

Każdy certyfikat wygasa, a nowy certyfikat ma nowy skrót, nawet gdy klucz i nazwy pozostają te same. Pod wystawcą odnowienie jest przezroczyste dla partnerów, którzy ufają temu wystawcy; pod przypinaniem jest to zdarzenie rejestracji dla każdego partnera, który przypina certyfikat.

Zaplanuj kolejność przed datą wygaśnięcia, a nie po niej. Rozprowadź nowy skrót do stron, które go weryfikują, zastosuj zmianę i dopiero potem wymień certyfikat w punkcie końcowym. Ta kolejność nie zostawia okna, w którym obie strony nie zgadzają się, który certyfikat jest aktualny. Utrzymuj też samą listę pod przeglądem, bo przypięta lista gromadzi wpisy urządzeń wycofanych miesiące temu. Każdy nieaktualny wpis to tożsamość, która wciąż się uwierzytelnia, jeśli jej klucz przetrwa, więc usunięcie jednego jest działaniem bezpieczeństwa, a nie porządkami.

Czego mapa zaufania nie rozstrzyga

Uwierzytelnianie to jedna warstwa, a przypięta mapa nie mówi nic o puli adresów, trasach wypychanych, MTU ścieżki ani polityce zapory. To pozostaje osobną konfiguracją z osobnymi trybami awarii. Tunel, który się uwierzytelnia i nie przepuszcza żadnego ruchu, to inne śledztwo niż ten, który nigdy nie wstaje.

Mapa też nie skaluje się bez końca, i PKI oparta na wystawcy jest miejscem, do którego trafiają większe wdrożenia. Ta preferencja dotyczy operacji, a nie kryptografii, bo dodawanie i wycofywanie tożsamości przez jeden organ jest tańsze niż edytowanie listy na każdym partnerze w miarę wzrostu floty. Tam, gdzie implementacja klienta nie obsługuje tej opcji, odpowiedzią jest kompatybilny model zaufania, który ten klient dokumentuje, albo obsługiwany zamiennik. Wyciszenie ostrzeżenia o weryfikacji nie dodaje tego wsparcia, a cała wartość tego projektu polega na tym, że weryfikacja nadal się odbywa.