OpenVPN tls-crypt-v2: co robią klucz klienta i opakowany blob

Wklejenie profilu tls-crypt-v2 do zgłoszenia wygląda nieszkodliwie, dopóki nie policzysz, co zawiera plik. Klucz kanału sterującego klienta stoi obok zaszyfrowanej kopii tego samego klucza, a trzeci obiekt, klucz opakowujący, nigdy nie opuszcza serwera, który akceptuje. Te trzy odpowiadają na różne pytania o przechowywanie, udostępnianie i wycofanie. Ich rozdzielenie rozstrzyga większość sporów o politykę, zanim się zaczną.

Co naprawdę zawiera profil

Połowa kliencka tls-crypt-v2 to klucz plus jego opakowana kopia. Klient używa zwykłego klucza do ochrony kanału sterującego i podczas konfiguracji przekazuje opakowaną kopię serwerowi, więc serwer odzyskuje ten sam klucz bez przechowywania kopii w czystym tekście dla każdego klienta. Klucz opakowujący umożliwia to odzyskanie i należy wyłącznie do strony akceptującej. Wszystko poniżej wynika z tego, gdzie żyją te trzy obiekty.

Czytaj tabelę według przechowywania, a nie według nazwy, a konsekwencje same się rozwiną. Utrata klucza opakowującego to kosztowne zdarzenie, bo nic w profilu nie może go odtworzyć, a uczciwe odzyskanie to ponowne wydanie grupy. Wyciekły profil jest tańszy, ale znacznie częstszy, bo ludzie wklejają profile do zgłoszeń w przekonaniu, że opakowana kopia czyni plik bezpiecznym do udostępniania. Te dwa błędy wymagają różnych reakcji i dlatego obiekty trzyma się osobno.

Dlaczego opakowana kopia to nie cała historia

Profil niesie użyteczny materiał klienta wraz z jego opakowanym odpowiednikiem, więc ochrona kopii dla serwera nic nie mówi o ochronie pliku. Blob jest bezpieczny do przesłania i niebezpieczny do publikacji. Metadane w nim są widoczne dla każdego, kto otrzyma blob, w tym dla każdego, kto później przeczyta zgłoszenie, do którego go wklejono.

Traktuj profil jak poświadczenie, a nie przykład konfiguracji. Wyciekły plik daje jego posiadaczowi działającą tożsamość klienta, dopóki serwer nie przestanie akceptować tej tożsamości, a opakowanie nic nie robi w tej kwestii. Wydawaj jeden profil na klienta, aby wycofanie pozostało decyzją o jednym pliku, i rób kopię zapasową klucza opakowującego oddzielnie od konfiguracji serwera, którą umożliwia. Żaden z tych nawyków nie naprawia przejętego profilu, ale oba decydują, jak szybko następny zostanie opanowany.

Gdzie w uścisku dłoni siedzi hak weryfikacji

Hak weryfikacji działa, zanim stos TLS zostanie wystawiony, a jego zadaniem jest sprawdzenie metadanych przenoszonych w opakowanym blobie. Otrzymuje te metadane plus małe, udokumentowane środowisko i ma mniej do pracy niż hak uwierzytelniania. Zakładanie, że widzi nazwy użytkowników, stan sesji lub zmienne wtyczek, to zwykły sposób złego napisania tego haka. Czytaj własną sekcję podręcznika haka, zamiast pożyczać oczekiwania od innego haka.

Jego status wyjścia jest decyzją: wynik niezerowy odrzuca klienta, a wynik zerowy pozwala uściskowi trwać dalej. Polityka musi więc mówić, co się dzieje, gdy metadanych brakuje, nie da się ich przeanalizować lub są nieoczekiwane. Najpierw napisz ścieżkę odmowy, potem zdecyduj, które wartości są dopuszczalne.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Te dwie linie to powierzchnia polityki na serwerze: jedna nazywa klucz opakowujący, druga nazywa program oceniający każdego klienta. Wszystko ciekawe żyje w skrypcie, który zasługuje na kontrolę wersji i taki sam przegląd jak każda inna reguła dostępu.

Konto, certyfikat i klucz sterujący wycofuje się osobno

Wczesna akceptacja kanału sterującego nie jest uwierzytelnieniem, bo następuje przed sprawdzeniem tożsamości TLS i przed jakąkolwiek autoryzacją konta. Wyłączenie konta, unieważnienie certyfikatu i odrzucenie klucza sterującego klienta to trzy działania z trzema mechanizmami. Wdrożenie, które wykonuje tylko jedno z nich, ma lukę, a nie politykę. Uzgodnij te trzy świadomie i zapisz, który krok wykonuje jakie uprawnienie.

Czas to druga różnica. Zmieniona lista akceptacji dotyczy nowych uścisków dłoni, a sesje już ustanowione działają dalej, dopóki coś ich nie zakończy. Liczenie wpisów na nowej liście jako dowodu, że stare sesje się skończyły, to sposób, w jaki usunięty klient pozostaje połączony godzinami.

Nieuzgodnione uprawnienia zostawiają dwie dziury, które w praktyce łatwo znaleźć. Konto może być wyłączone, podczas gdy jego klucz sterujący wciąż otwiera uścisk dłoni, a certyfikat może być unieważniony, podczas gdy polityka metadanych wciąż dopuszcza tego samego klienta. Oba to ten sam błąd w różnych miejscach, bo operator potraktował jedną listę jako całe uprawnienie. Połóż trzy listy obok siebie w momencie usuwania, a błąd stanie się widoczny.

Wydawanie i wycofywanie profilu

Wydawanie to łatwiejsza połowa: utwórz klucz klienta po stronie akceptującej, przekaż profil dokładnie jednemu właścicielowi, trzymaj materiał opakowujący w ograniczeniu i uruchamiaj ten sam program weryfikacji na każdym akceptującym serwerze. Tani dostęp jest cechą całej grupy, a nie najnowszego hosta. Drugi serwer ze starszym lub luźniejszym skryptem po cichu staje się najsłabszą ścieżką we wdrożeniu.

Wycofanie wymaga trzech kroków w świadomej kolejności. Odrzuć klienta w haku weryfikacji, aby nowe uściski dłoni zawiodły, unieważnij jego certyfikat, jeśli używana jest PKI, i wyłącz konto, aby późniejsza autoryzacja nie miała czego autoryzować. Następnie zakończ sesje, które pozwalała stara akceptacja, bo nie zauważą żadnego z trzech. Przećwicz sekwencję na kliencie, na którego zepsucie możesz sobie pozwolić.

Metadane w profilu są wejściem dla tej polityki, a nie dowodem, że kontrola dostępu już istnieje. Dokument projektowy OpenVPN 2.6 opisuje obiekty i granicę, którą wyznaczają, a egzekwowanie pozostaje po stronie operatora.