Plik DH czy klucz tls-auth? Rozróżnianie dwóch plików OpenVPN

Dwa pliki, dwie dyrektywy i nawyk nazywania obu tym, co konfigurują. Tak dh.pem trafia do wiersza tls-auth, a klient zawodzi z komunikatem o nieoczekiwanym formacie klucza. Decyzja przed tobą nie dotyczy tego, który plik jest mocniejszy. Chodzi o to, jakiej roli naprawdę potrzebuje wdrożenie, i trzy warunki to rozstrzygają: jaką wymianę kluczy wynegocjuje twój stos TLS, czy w ogóle chcesz uwierzytelniania kanału sterującego i czy materiał musi pozostać tajny.

Odpowiedz na nie po kolei, a pytanie o plik odpowie samo. Pominięcie ich sprawia, że nazwy dyrektyw zaczynają wyglądać wymiennie, i dokładnie z tego stanu bierze się błąd.

Przeczytaj etykietę przed nazwą pliku

Pierwszy wiersz pliku mówi więcej niż jego nazwa, bo nazwa jest ludzką konwencją, a etykietę tworzy narzędzie. Parametry Diffie-Hellmana noszą etykietę PEM BEGIN DH PARAMETERS. Statyczny klucz OpenVPN to zupełnie inna struktura, z własnym nagłówkiem i ładunkiem szesnastkowym.

Zmiana nazwy niczego nie konwertuje. Plik parametrów o nazwie ta.key nadal jest parametrami, a statyczny klucz o nazwie dh.pem nadal jest statycznym kluczem; parser czyta zawartość i odrzuca niezgodność. Sprawdź przed edycją profilu:

head -n 1 dh.pem
head -n 1 ta.key

Trzy warunki, które decydują, którego pliku potrzebujesz

Pierwszy warunek to wymiana. Uścisk dłoni Diffie-Hellmana w ciele skończonym wymaga grupy, a dyrektywa dh jest miejscem, w którym serwer nazywa dla niej parametry. Uścisk dłoni na krzywej eliptycznej wcale nie potrzebuje tego pliku, bo krzywa jest zbiorem parametrów. Jeśli twój serwer negocjuje tylko zestawy ECDHE, plik DH jest martwym balastem, a nie dodatkową siłą.

Drugi warunek to uwierzytelnianie kanału sterującego, osobna funkcja z własnym materiałem. Plik tls-auth to wspólny klucz statyczny, który mają obie strony i którym podpisuje się pakiety kanału sterującego, aby nieuwierzytelniona strona nie mogła nawet dokończyć uścisku dłoni. Istnieje niezależnie od tego, czy używasz DH w ciele skończonym, i nie ma nic wspólnego z parametrami grupy.

Trzeci warunek to tajność i dystrybucja. Parametry DH można publikować bez osłabiania sesji, bo tajne wartości są generowane dla każdego uścisku dłoni i nigdy nie opuszczają stron. Statycznego klucza nie wolno publikować: to te same bajty po obu stronach, nie obraca się sam, a kto go ma, może tworzyć ważne podpisy kanału sterującego. Te dwie odpowiedzi prowadzą do zupełnie różnych zasad postępowania, dlatego jeden plik może leżeć w repozytorium, a drugi nie.

Wygeneruj odpowiedni materiał dla każdej roli

Użyj narzędzia, które tworzy format oczekiwany przez dyrektywę, zamiast konwertować między nimi. Dla wspólnego klucza w OpenVPN 2.6 typowana postać generatora wprost podaje cel.

openvpn --genkey tls-auth ta.key

To polecenie tworzy nowy tajny materiał; nie naprawia ani nie sprawdza istniejącego klucza, a ponowne uruchomienie daje inny klucz, którego nie mają inne strony. Skopiuj wynikowy plik do stron, które go potrzebują, kanałem, którego użyłbyś do każdego wspólnego sekretu, i utrzymuj spójną konwencję kierunku: z tls-auth jedna strona używa key-direction 0, a druga key-direction 1.

Parametry DH, gdy są potrzebne, pochodzą z generowania parametrów, a nie z generatora kluczy, i ich pochodzenie ma znaczenie nawet wtedy, gdy wynik jest publiczny. Grupa wzięta z nieznanego źródła nie staje się wiarygodna dlatego, że jest publiczna; nadal musi być grupą, na którą zgadzają się twoje strony, i taką, której nie osłabia jej rozmiar ani konstrukcja.

Co oznacza dh none, a czego nie oznacza

dh none to prawdziwa dyrektywa o wąskim znaczeniu: żaden plik parametrów ciała skończonego nie zostanie wczytany, bo uścisk dłoni używa Diffie-Hellmana na krzywej eliptycznej. To nie skrót oznaczający „pomiń krok DH” w sensie osłabiania czegokolwiek i z pewnością nie mówi OpenVPN, by zaakceptował inny plik jako zamiennik.

Dwa błędy wynikają z błędnego czytania. Pierwszy to założenie, że dh none usuwa potrzebę tls-auth, choć oba sterują różnymi rzeczami. Drugi to trzymanie nieaktualnego wiersza dh obok konfiguracji tylko z krzywą i zastanawianie się, którego pliku serwer faktycznie używa; jeśli dyrektywa jest obecna, plik jest czytany, a zepsuta ścieżka powoduje niepowodzenie startu z powodu niezwiązanego z wymianą, która będzie negocjowana.

Jeśli niewłaściwy plik został już wdrożony

Przywróć zamierzony sekret od właściciela profilu i nie ruszaj weryfikacji certyfikatu, gdy to robisz. Awaria to niezgodność formatu, nie awaria zaufania, a wyłączenie weryfikacji, by obejść błąd, zastępuje problem startu cichym problemem.

Następnie rozdziel dwa zdarzenia, które ludzie mają zwyczaj łączyć. Publikacja pliku parametrów DH jest prawie nieszkodliwa, bo parametry były publiczne z założenia. Ujawnienie klucza tls-auth to inne zdarzenie: klucz uwierzytelnia pakiety kanału sterującego dla każdej strony, która go ma, więc wymianę trzeba skoordynować w całym wdrożeniu, a nie zastosować na jednym hoście.

Sprawdzenie w pięć minut rozstrzyga, w którym przypadku jesteś: przeczytaj pierwszy wiersz każdego pliku, potwierdź dyrektywę, która się do niego odwołuje, i potwierdź, że dystrybucja pliku odpowiada temu, czego wymaga materiał. To mniejsza praca niż ponowne wygenerowanie działającego PKI, i na to trzy warunki wskazywały przez cały czas.