tls-auth kontra tls-crypt: co chroni każda z opcji w OpenVPN

Obie opcje korzystają ze wspólnego pliku klucza i obie utrudniają sfałszowanie ruchu uzgadniania, dlatego traktuje się je jako dwie nazwy tej samej funkcji. Nie są nimi. Jedna podpisuje pakiety sterujące, druga je dodatkowo szyfruje, a żadna nie ma nic wspólnego z szyfrem chroniącym Twoje dane.

To rozróżnienie ma znaczenie, gdy profil nie może się połączyć, gdy przegląd bezpieczeństwa pyta, co chroni klucz, i gdy ktoś zakłada, że dodatkowy plik czyni tunel zaszyfrowanym w jakiś nieokreślony sposób.

Co naprawdę chroni wspólny klucz

Klucz używany przez te opcje należy do kanału sterującego: wymiany, która negocjuje parametry, dowodzi tożsamości i wyprowadza klucze danych. To wcześniej udostępniony sekret, który obie strony muszą mieć, zanim uzgadnianie będzie mogło trwać. Ponieważ znajduje się przed weryfikacją tożsamości, błędny klucz zatrzymuje rozmowę wcześniej, niż zrobiłoby to błędne hasło. Ta kolejność wyjaśnia, dlaczego tryb awarii jest tak cichy.

tls-auth używa tego sekretu do obliczenia HMAC na pakietach sterujących. Pakiet bez ważnego podpisu jest odrzucany, zanim dotrze do droższego przetwarzania TLS, dlatego opcję często opisuje się jako pierwszy filtr, a nie zamiennik TLS.

tls-crypt idzie dalej, szyfrując chroniony ruch sterujący oprócz uwierzytelniania go. Zawartość certyfikatów, wynegocjowane nazwy szyfrów i inne szczegóły uzgadniania nie są już widoczne w sieci, a obserwator bez klucza nie widzi nawet, która wersja TLS jest próbowana. Dla wdrożenia, które obawia się ujawnienia swojego odcisku VPN, ta właściwość jest głównym powodem wyboru. To nadal wspólny sekret grupy, a nie poświadczenie dla pojedynczego użytkownika.

Żaden z mechanizmów nie wydaje tożsamości. Wspólny klucz jest sekretem grupy, a każdy, kto go ma, może spełnić tę warstwę kontroli.

Czym różnią się obie opcje

Dostrzegalna różnica to to, co widzi obserwator. Z tls-auth uzgadnianie jest widoczne, ale bez klucza nie do zweryfikowania. Z tls-crypt uzgadnianie jest nieprzejrzyste dla każdego, kto nie ma klucza.

Konfiguracja też się różni. tls-auth używa się z wartością kierunku, więc jedna strona używa jednej połowy materiału klucza, a druga drugiej. tls-crypt używa jednego klucza w obu kierunkach, więc dyrektywa kierunku nie jest częścią jego układu.

W nowoczesnych wydaniach obie opcje wykluczają się wzajemnie. Profil powinien zawierać jedną z nich, nie obie, a serwer i klient muszą uzgodnić którą, z pasującym materiałem klucza. Trzymanie starej dyrektywy obok nowej to częsty pozostałość po migracji. Usuń nieaktywną, aby następny czytelnik wiedział, która warstwa faktycznie obowiązuje.

Nowszy wariant, tls-crypt-v2, wiąże każdego klienta z jego własnym opakowanym kluczem, dzięki czemu odwołanie jednego klienta nie wymaga ponownego wydania klucza grupy. Warto o nim wiedzieć, ale to inna opcja i nie synonim żadnej z tych dwóch.

Dlaczego niezgodność wygląda, jakby nic się nie działo

Gdy wspólny materiał się nie zgadza, druga strona odrzuca pakiety, nie mówiąc nadawcy dlaczego. Nie ma błędu uwierzytelniania do przeczytania, ponieważ pakiet nigdy nie dotarł do warstwy, która by go wytworzyła.

Klient ponawia, serwer nic nie mówi, a objaw wygląda jak problem sieci. Wtedy ludzie restartują usługę, wpisują ponownie hasło konta albo usuwają dyrektywę ochrony, aby ją «przetestować», co zmienia wdrożenie zamiast je zdiagnozować.

Czytaj w logu serwera pierwszą skargę na poziomie pakietów, a nie ostatnią linię ponowienia. Potwierdź, że obie strony mają tę samą opcję z identycznym materiałem klucza i że plik klucza nie został wygenerowany ponownie tylko po jednej stronie.

Usunięcie dyrektywy nie jest bezpieczną naprawą. Wyłącza warstwę ochrony dla każdego klienta, a działający potem tunel dowodzi tylko, że ta warstwa była niezgodnością.

Co nadal trzeba skonfigurować osobno

Te opcje nie weryfikują, kim jest druga strona. Weryfikacja certyfikatów, zaufany korzeń i oczekiwana nazwa serwera pozostają osobnymi wymaganiami i żadne z nich nie staje się opcjonalne z powodu obecności wspólnego klucza.

Nie wybierają też szyfru danych. To osobne negocjacje kontrolowane przez ustawienia kanału danych po obu stronach, a tunel chroniony przez tls-crypt nadal może używać szyfru, którego nie zamierzałeś.

Na koniec sam wspólny klucz wymaga obchodzenia się. Traktuj go jak sekret, rozprowadzaj zatwierdzonym kanałem i wymień go, gdy odejdzie ktokolwiek, kto go miał. Ponieważ jest wspólny, jego ujawnienie jest ujawnieniem każdego punktu końcowego, który go używa.