Które pakiety OpenVPN chroni skrót auth?
Opcja auth obejmuje mniej, niż sugeruje profil. Przejrzyj kanał, przypadek AEAD i ochronę kanału sterującego, zanim ustalisz politykę skrótu.
Większość sporów o skróty OpenVPN zaczyna się od niewłaściwego pakietu. Czytanie auth SHA256 jako „akceptuj tylko te peery, które oferują SHA256” to pierwsza rzecz, której trzeba się oduczyć. Opcja nazywa skrót dla określonych pakietów, a to, które to pakiety, zależy od kanału i od tego, czy ten kanał jest AEAD. Przejdź po kolei przez cztery pytania poniżej; każde zawęża to, co ustawienie może oznaczać w twoim wdrożeniu.
Nazwij kanał, który ustawienie ma chronić
OpenVPN ma kanał sterujący, który przenosi ruch uścisku dłoni TLS, oraz kanał danych, który przenosi ładunek tunelu. Skrót auth odgrywa rolę w obu, ale nie tę samą, a profil rzadko czyni różnicę widoczną. Zapisz, który z dwóch próbujesz ograniczyć, zanim dotkniesz pliku konfiguracyjnego.
Poniższa tabela to skrócona wersja tego, jak ta sama opcja trafia w każdy kontekst.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Sprawdź, czy kanał danych jest AEAD, zanim na nim polegniesz
Jeśli wynegocjowany szyfr danych to AES-GCM lub CHACHA20-POLY1305, kanał danych uwierzytelnia sam siebie, a osobny skrót nie wykonuje pracy, którą być może sobie wyobrażasz. Oba są konstrukcjami AEAD, więc integralność powstaje w tej samej operacji, która szyfruje ładunek. To nie jest obniżenie poziomu, ale oznacza, że polityka uzasadniana jako „każdy pakiet danych to HMAC-SHA256” jest na tym tunelu faktycznie błędna. Potwierdź wynegocjowaną wartość w logu serwera lub w wyjściu statusu klienta, zanim przepiszesz politykę.
Sprawdź szyfr, który rzeczywiście wynegocjowano, a nie listę w profilu, bo negocjacja może trafić na innego członka zbioru. data-ciphers AES-256-GCM:AES-128-GCM to lista negocjacyjna, a oba wpisy są AEAD, więc żaden z nich nie zużywa skrótu auth do ochrony ładunku.
Traktuj ochronę kanału sterującego jako osobną decyzję
tls-auth dodaje HMAC do pakietów kanału sterującego i bierze swój skrót z ustawienia auth, dlatego tunel AEAD nadal może mieć sensownie ustawiony skrót. tls-crypt to inne rozwiązanie z własną stałą ochroną, więc nie zakładaj, że dziedziczy każdą właściwość tls-auth. Czytaj dokumentację wybranego mechanizmu, zamiast przenosić założenia między nimi.
Dwa peery muszą też zgodzić się co do rozwiązania i co do kierunku klucza. Pasujący skrót, ale plik klucza użyty w złym kierunku daje uścisk dłoni, który kończy się niepowodzeniem z powodów, których ustawienie skrótu nie potrafi wyjaśnić.
Trzymaj auth osobno od negocjacji szyfrów i certyfikatów
Trzy ustawienia są stale mylone: skrót auth, lista szyfrów danych i algorytm podpisu certyfikatu. Zmiana pierwszego nie wystawia certyfikatu ponownie, nie wybiera jego skrótu podpisu i nie tworzy metody użytkownik-hasło. Definicje opcji protokołu w źródłach OpenVPN 2.6 opisują każdą w osobnym rozdziale, co jest użytecznym przypomnieniem, że to niezależne pokrętła.
Gdy peer odmawia połączenia po zmianie skrótu, przyczyną jest zwykle niezgodność w jednym z dwóch pozostałych ustawień. Przeczytaj oba końce, zanim zmienisz którekolwiek.
Zapisz politykę i porównaj ją z działającymi konfiguracjami
Oświadczenie na poziomie floty powinno w tym samym zdaniu wyraźnie wymienić dozwolone tryby kanału danych i wybraną ochronę kanału sterującego. To zdanie jest testowalne; „używamy SHA256” nie jest. Następnie porównaj je z efektywnymi profilami serwera i klienta, a nie z szablonem w repozytorium.
Zakończ zapisaniem, co każdy tunel faktycznie wynegocjował i który mechanizm uwierzytelnił jego pakiety. Widoczna linia auth w profilu jest jedynie dowodem intencji konfiguracji, a intencja to najtańsza część sprawdzenia.