Śledzenie pakietów sterujących OpenVPN: tls-auth przed TLS

Błąd tls-auth jest zwykle zgłaszany jako problem uzgadniania, choć nigdy nim nie był. HMAC jest sprawdzany na pakiecie sterującym, zanim rozpocznie się jakiekolwiek przetwarzanie TLS, więc niepasujący klucz lub kierunek daje błąd, który wygląda jak problem certyfikatu i jest rozstrzygany dwie warstwy wcześniej. Potraktowanie koperty jako osobnego obiektu skraca diagnozę: przeczytaj pola, potwierdź, że sprawdzenie następuje wcześnie, a następnie porównaj trzy rzeczy, co do których obie strony muszą się zgodzić.

Czytaj kopertę w kolejności, w jakiej jest budowana

Pakiet sterujący niesie identyfikator sesji, opcjonalny HMAC tls-auth, informacje o powtórzeniach i potwierdzeniach oraz niezawodny identyfikator komunikatu, a po tym następuje ładunek typu komunikatu. Gdy komunikat jest komunikatem uzgadniania, ładunkiem jest przypadkiem tekst zaszyfrowany TLS. Cała zależność jest właśnie taka: materiał TLS podróżuje wewnątrz komunikatu, który koperta już chroni. Zobacz dokumentację protokołu sieciowego OpenVPN która wymienia pola kanału sterującego w tej kolejności.

Warstwę niezawodności łatwo pomylić z kryptografią. Potwierdzenia, retransmisja i identyfikator komunikatu istnieją po to, aby komunikaty sterujące docierały raz i w odpowiedniej kolejności przez zawodny transport. Nie są uwierzytelnianiem, a poprawny identyfikator komunikatu niczego nie dowodzi o tym, kto wysłał pakiet.

Traktuj to grupowanie pojęciowo. Nie jest to diagram kolejności bajtów i nie wystarcza do obliczenia znacznika, ponieważ pola wchodzące do HMAC zależą od implementacji, wersji i trybu.

Pokaż, że sprawdzenie następuje przed uzgadnianiem

Odbiorca mający klucz współdzielony może zweryfikować HMAC i natychmiast odrzucić sfałszowany pakiet, bez przydzielania stanu uzgadniania i bez pracy z kluczem publicznym. Ochrona obejmuje także pierwsze pakiety uzgadniania, dlatego właśnie zły klucz objawia się jako nieudane połączenie, a nie jako późny błąd uwierzytelniania.

Zwiększ gadatliwość demona i obserwuj kanał sterujący, a nie urządzenie tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Szukasz niepowodzenia weryfikacji HMAC kanału sterującego zgłaszanego na poziomie pakietu, przed jakimkolwiek alertem TLS. Alert TLS w logu oznacza, że koperta została przyjęta, a błąd przesunął się do środka, co jest innym śledztwem z innym rozwiązaniem.

Obsługa kierunku też tu jest. Gdy statyczny plik klucza jest używany z tls-auth, obie strony przyjmują przeciwne kierunki klucza, a protokół wykorzystuje ten podział, aby przechwycony pakiet nie mógł zostać odbity z powrotem do nadawcy. Odwrócenie kierunku pozostawia ten sam klucz i mimo to każdy pakiet zawodzi. Zmieniaj jedną stronę naraz, a potem zrestartuj oba demony, aby para została wczytana razem.

Dopasuj klucz, kierunek i digest po obu stronach

Trzy wartości muszą się zgadzać i tylko jedna z nich jest plikiem. Zawartość statycznego klucza musi być identyczna po obu stronach, kierunek musi być przeciwny, a digest używany do HMAC musi się zgadzać. Sprawdź konfigurację, zanim dotkniesz materiału klucza, bo jeden odwrócony kierunek wyjaśnia więcej błędów niż uszkodzony plik:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Generuj współdzielony sekret narzędziem, a nie edytorem, i utrzymuj uprawnienia wąskie:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Starsze wydania akceptowały nieco inną kolejność opcji generowania klucza, a profile napisane dla tych wydań wciąż krążą. Wygenerowany plik jest w obu przypadkach tym samym rodzajem obiektu, więc sprawdzenie polega na tym, czy obie strony mają identyczne bajty, a nie na tym, która pisownia je utworzyła.

Nie myl tls-auth z tls-crypt. Oba chronią kanał sterujący, ale tls-crypt dodatkowo go szyfruje i ukrywa uzgadnianie przed obserwatorami, i zastępuje podział kierunków własną obsługą kluczy. Profil używający jednego nie będzie współpracował z pełem skonfigurowanym dla drugiego, a żadne strojenie digestu nie zamyka tej luki.

Odtwarzaj znacznik tylko z rzeczywistego formatu

Odtworzenie co do bajtu to osobne zadanie od uruchamiania VPN i działa tylko z rzeczywistymi danymi wejściowymi: implementacją i wersją, które zbudowały pakiet, wybranym digestem, kierunkiem oraz faktycznymi bajtami, w tym identyfikatorem sesji i tablicą potwierdzeń. Tekstowe przedstawienie listy pól nie jest tymi bajtami.

Długość znacznika wynika z digestu, więc założenie stałej długości łamie się w momencie, gdy ktoś ją zmieni. Haszuj pakiet tak, jak robi to implementacja, a nie tak, jak przedstawia go tabela we wpisie blogowym, i porównuj z zapisem pobranym od tego samego peła, a nie z oczekiwaniem wyprowadzonym ręcznie.

Trzymaj to ćwiczenie z dala od profili produkcyjnych. Nic w odtwarzaniu znacznika nie mówi, czy wdrożenie powinno włączyć ochronę.

Wycofaj niezgodność bez usuwania ochrony

Kuszący test to usunięcie tls-auth, obejrzenie udanego połączenia i wniosek, że klucz był zły. Ta odpowiedź kosztuje ochronę i niczego nie uczy o tym, która z trzech wartości się nie zgadzała. Zamiast tego pobierz zatwierdzoną pasującą konfigurację ze strony serwera i porównaj z nią.

Przygotuj zmianę tak, aby była odwracalna. Zachowaj poprzednią konfigurację serwera i plik klucza, zastosuj poprawioną parę, sprawdź, że klient kończy uzgadnianie, i dopiero wtedy usuń kopię zapasową. Jeśli klienci zawiodą po zmianie, przywróć poprzednie pliki, zamiast improwizować trzeci wariant podczas awarii. Przywrócenie powinno być jednym poleceniem, które już znasz przed rozpoczęciem.

Na koniec pamiętaj, co oznacza zdane sprawdzenie. Dowodzi, że peło ma klucz współdzielony, a nie że jego certyfikat lub konto jest autoryzowane, i nie mówi nic o wynegocjowanym szyfrze kanału danych. Autoryzacja i ochrona danych są ustanawiane później, więc czyste sprawdzenie koperty jest punktem wyjścia, a nie wyrokiem.