Dziennik OpenVPN: szyfr kanału sterującego a szyfr kanału danych

Wiersz dziennika, który wymienia DHE-RSA-AES256-SHA, nie jest podsumowaniem całego połączenia. Należy do uzgadniania TLS, które chroni kanał sterujący, a ruch wewnątrz tunelu może być szyfrowany zupełnie inaczej. Podawanie go jako szyfru danych VPN to błąd, którego trzeba unikać.

Znaczenie mają dwa wyniki i odpowiadają one na różne pytania. Jeden to wynegocjowany zestaw TLS dla kanału sterującego; drugi to szyfr danych pakietów przenoszonych przez tunel.

Dwa wyniki, dwa pytania

Kanał sterujący przenosi uzgadnianie i komunikaty zarządzające między stronami. Jego szyfr wybiera stos TLS, więc nazwa podąża za konwencjami TLS. Kanał danych przenosi ruch użytkownika i jest konfigurowany przez własne negocjacje szyfru OpenVPN.

Zdecyduj, na które pytanie odpowiadasz, zanim przeczytasz którykolwiek wiersz. Czy tunel jest szyfrowany i czy uzgadnianie jest mocne, to nie to samo pytanie.

Przydatny jest fragment dziennika, który pokazuje oba wiersze. Przeczytaj wiersz sterujący pod kątem wersji i zestawu TLS, a wiersz danych pod kątem algorytmu, który naprawdę chroni ładunek.

Odczytaj nazwę zestawu TLS we właściwym kontekście

W historycznej nazwie w stylu OpenSSL, takiej jak DHE-RSA-AES256-SHA, każdy składnik opisuje inną decyzję. DHE to efemeryczne uzgodnienie kluczy Diffiego-Hellmana, RSA to metoda uwierzytelniania, AES256 to AES-256 w trybie CBC dla rekordów TLS, a SHA to MAC rekordu oparty na SHA-1.

Ostatni składnik nie jest odciskiem certyfikatu, a czytanie go jako odcisku to częsty błąd. Nazwa nie podaje też sama wersji protokołu, ponieważ TLS 1.3 używa zupełnie innego schematu nazewnictwa. TLS_AES_256_GCM_SHA384 idzie za tą nowszą formą, w której końcowy skrót jest częścią budowy zestawu, a nie wyborem MAC. Stosuj czytanie składników tylko do starszego stylu nazewnictwa.

Dokumentacja zestawów OpenSSL wiąże te nazwy z ich definicjami, jeśli jakiś składnik jest nieznany.

Odczytaj wynik kanału danych dla przenoszonego ruchu

Dla przenoszonego ruchu odczytaj wiersz kanału danych z tej samej sesji. Lista data-ciphers w konfiguracji to dozwolony zbiór, a nie dowód, że wynegocjowano konkretny algorytm. Dziennik zapisuje wybór; konfiguracja podaje menu.

Szyfr AEAD, taki jak AES-GCM, zawiera własną kontrolę integralności, więc osobny HMAC kanału danych nie jest częścią tej ścieżki.

Dyrektywa auth nie podnosi TLS, certyfikatów ani szyfru danych. Wybiera skrót dla tych części protokołu, które nadal go używają, a przy szyfrze danych AEAD nie ma osobnego HMAC danych do skonfigurowania.

Trzymaj kontrole tożsamości poza wynikiem szyfru

Algorytm podpisu certyfikatu, walidacja łańcucha zaufania i weryfikacja nazwy drugiej strony to trzy kolejne właściwości, o których nazwa szyfru nic nie mówi. Wygasły certyfikat zawodzi niezależnie od tego, jak mocny jest zestaw. Niezgodna nazwa serwera zawodzi w ten sam sposób. Poprawienie ustawienia skrótu w profilu nie naprawia żadnego z nich.

Trzymaj te kontrole w notatkach z przeglądu obok wyniku szyfru, a nie scalone z nim.

Zapisz wynegocjowane wyniki bieżącej sesji

Weź wyniki z bieżącego połączenia i zapisz razem wersje klienta i serwera. Dziennik tylko dopisywany może zawierać wiersz starszej sesji, a cytowanie go jako bieżącego sprawia, że naprawiony problem wygląda na trwający.

Do przeglądu polityki przekaż właścicielowi konfiguracji wynegocjowaną wersję i zestaw TLS, wybrany szyfr danych i ustawienia walidacji certyfikatu razem. Zmień tę warstwę, a następnie odczytaj nowy dziennik, aby potwierdzić nowe wynegocjowane wartości.