Dlaczego większy klucz OpenVPN nie usuwa licznika odświeżania kluczy

Wybór AES-256 lub dłuższego klucza nie mówi nic o tym, jak długo ten klucz może być używany. Siła klucza opisuje algorytm; polityka odświeżania decyduje, kiedy sesja wyprowadza nowy materiał klucza. Wdrożenie może wybrać najsilniejszy dostępny szyfr i nadal pomylić się co do odnowienia, bo obie decyzje podejmowane są w różnych miejscach. Mieszanie ich daje albo niepotrzebną zmianę szyfru, albo sesję, która po cichu przeżywa swoją politykę.

Przeczytaj ustawienia odświeżania, zanim dotkniesz szyfru, a robiąc to, czytaj obie strony.

Siła klucza i żywotność klucza odpowiadają na różne pytania

Szyfr i rozmiar klucza ograniczają, jak kosztowny byłby atak na przechwycony ruch. Interwał odświeżania ogranicza, ile ruchu chroni jeden klucz i jak długo ujawniony klucz pozostaje użyteczny. To niezależne ustawienia, a silniejszy szyfr nie wydłuża bezpiecznego okresu życia sesji. Większość porad mówiących „używaj AES-256” milczy o odnowieniu, bo odnowienie jest kwestią polityki, a nie wyborem algorytmu.

Zapisz oba w notatkach wdrożeniowych: co chroni kanał danych i co wyzwala wymianę jego kluczy.

Odświeżanie ma trzy wyzwalacze, a każda strona może je uruchomić

OpenVPN 2.6 dokumentuje osobne wyzwalacze renegocjacji oparte na bajtach, pakietach i upływie czasu. Wyzwalacz czasu jest tym, który większość wdrożeń zostawia na wartości domyślnej, co oznacza, że cichy tunel i tak odświeża klucz zgodnie z harmonogramem. Każda strona może rozpocząć wymianę, a strona, która jej nie rozpoczęła, podąża za nią. Zmiana licznika po jednej stronie nie ustala więc zachowania sesji; skuteczna wartość należy do strony, która zaczyna pierwsza.

Wyzwalacze bajtów i pakietów mają znaczenie przy obciążeniach o dużej przepustowości lub małych pakietach, gdzie polityka oparta tylko na czasie pozwoliłaby jednemu kluczowi chronić znacznie więcej danych, niż zamierzano. Jeśli te liczniki pozostają wyłączone, powiedz to świadomie w notatkach, zamiast zostawiać wartość domyślną bez zbadania.

Odświeżenie ujawnia proces uwierzytelniania

Renegocjacja to nowy uścisk dłoni TLS, co oznacza, że ścieżka uwierzytelniania przebiega ponownie. Wdrożenia z kodami jednorazowymi, tokenami sprzętowymi lub wyzwaniem RADIUS przekonują się o tym w trudny sposób: pierwsze połączenie działa, a sesja ginie godzinę później, gdy drugi uścisk dłoni prosi o kod, który już został użyty. auth-gen-token istnieje po to, by wypełnić tę lukę, pozwalając serwerowi wydać krótkotrwały token do renegocjacji zamiast żądać nowego logowania interaktywnego.

Traktuj to jako problem przepływu pracy do rozwiązania z operatorem, a nie jako dowód, że odnowienie trzeba wyłączyć.

Testuj odnowienie pod obciążeniem, a nie w jednominutowej sesji

Test akceptacyjny, który się łączy, raz pinguje i rozłącza, nigdy nie dociera do odświeżenia. Uruchom sesję wystarczająco długą, by przekroczyć skonfigurowany wyzwalacz, utrzymuj transfer przez cały czas i obserwuj dzienniki obu stron w poszukiwaniu nowego uścisku dłoni. Potem przetestuj ścieżkę awarii: co robi klient, jeśli renegocjacji nie da się dokończyć. Tunel, który spada czysto, łatwiej zdiagnozować niż taki, który dalej wysyła do martwej sesji.

Nie czytaj udanego dużego transferu jako dowodu progu kryptograficznego. Pokazuje on tylko, że ścieżka i liczniki wytrzymały tyle ruchu.

Udokumentuj oba wybory

Zapis potrzebuje dwóch linii: jak chronione są pakiety i kiedy ta ochrona jest wymieniana. Dodaj umocowanie dla każdej wartości, bo szyfr może pochodzić z domyślnego ustawienia dystrybucji, a licznik z polityki wewnętrznej. Przyszły operator nie powinien musieć wnioskować żadnego z nich z pliku konfiguracyjnego.

Jeśli zgodność wymusza wyjątek, ogranicz go do wersji i daty końcowej. Wyjątek, który przeżywa swój powód, staje się polityką, której nikt nie pamięta, że wybrał.