Czy certyfikat RSA może działać z dh none w OpenVPN?

Oto konfiguracja serwera, która obok certyfikatu z RSA podaje dh none, plus dokuczliwe podejrzenie, że jedno z nich musi być błędne. Nic nie jest błędne. Certyfikat podpisuje i uwierzytelnia; wymiana kluczy ustanawia wspólny sekret. To dwa różne zadania w tym samym uzgadnianiu, a TLS pozwala certyfikatowi RSA uwierzytelnić uzgadnianie, które używa efemerycznego porozumienia na krzywej eliptycznej.

Zamieszanie zwykle przychodzi z przewodnikiem migracji. Mówi on, aby zastąpić plik parametrów DH przez dh none, czytelnik zauważa, że certyfikat nie jest certyfikatem krzywej eliptycznej, a oba fakty są traktowane jako sprzeczność.

Dlaczego oba ustawienia wydają się powiązane

Starsza konfiguracja OpenVPN wymagała pliku parametrów DH, ponieważ Diffie-Hellman w ciele skończonym potrzebuje parametrów domeny, co do których obie strony się zgadzają. Dyrektywa dh wskazywała na ten plik. Gdy wdrożenie przechodzi na ECDH, parametry pochodzą z nazwanej krzywej, a plik nie jest już potrzebny, co wyraża dh none.

Certyfikaty to osobna oś. Niosą klucz publiczny i podpis, które dowodzą tożsamości serwera, a ten klucz może być RSA lub krzywą eliptyczną niezależnie od tego, jak uzgadniany jest klucz sesji. Uzgadnianie, które używa ECDHE do uzgodnienia klucza i RSA do uwierzytelnienia, jest zwykłe i szeroko wdrożone.

Nazewnictwo pogarsza nakładanie się. Krzywa eliptyczna pojawia się w nazwach zestawów ECDHE i ECDSA, więc łatwo założyć, że każde połączenie wspominające krzywą musi zawierać certyfikat krzywej. Tak nie jest.

Jak poprawnie czytać nazwę zestawu TLS 1.2

Weź ECDHE-RSA-AES256-GCM-SHA384. Pierwszy token to rodzina wymiany kluczy: efemeryczny Diffie-Hellman na krzywej eliptycznej. Drugi to rodzina uwierzytelniania: RSA. Reszta opisuje ochronę rekordów i skrót używany w uzgadnianiu.

Zestaw ECDHE-ECDSA używa tej samej rodziny wymiany kluczy z inną metodą uwierzytelniania, więc potrzebuje certyfikatu krzywej eliptycznej. Zestaw DHE-RSA używa efemerycznego Diffie-Hellmana w ciele skończonym z uwierzytelnianiem RSA, i ten naprawdę potrzebuje parametrów DH.

Czytaj nazwę zestawu od lewej do prawej i przypisz każdą część do jej zadania. Gdy tokeny zostaną rozdzielone, pytanie zmienia się z „czy mój certyfikat pasuje do dh none” na „czy mój serwer dopuszcza zestaw, którego wymiana kluczy nie wymaga pliku DH”.

Co dh none naprawdę wyłącza

dh none każe serwerowi nie ładować pliku parametrów DH w ciele skończonym. Nie wyłącza uwierzytelniania, walidacji certyfikatów ani samego TLS. Wymaga jednak, aby wynegocjowana wymiana kluczy nie potrzebowała tych parametrów, co w praktyce oznacza zestaw ECDHE lub uzgadnianie TLS 1.3.

Właśnie z tego wymogu bierze się awaria. Jeśli polityka szyfrów TLS serwera jest ograniczona do zestawów DHE albo klient oferuje tylko je, usunięcie pliku parametrów nie pozostawia żadnej użytecznej metody wymiany kluczy i uzgadnianie kończy się niepowodzeniem. Błąd pojawia się zwykle podczas uzgadniania kanału sterującego, przed jakimkolwiek uwierzytelnieniem użytkownika. Przeczytaj listę szyfrów, zanim obwinisz brakujący plik.

Po stronie krzywej eliptycznej krzywą wybiera konfiguracja TLS serwera, a OpenVPN oferuje opcję wyboru jej w starszych gałęziach. TLS 1.3 obsługuje negocjację grupy wewnątrz protokołu i w ogóle nie zagląda do pliku DH.

dh none samo w sobie nie jest obniżeniem bezpieczeństwa. Siła wymiany zależy wtedy od krzywej i zestawu, które faktycznie wynegocjowano, dlatego następnym krokiem jest spojrzenie na to, co wybrały strony, a nie na brakujący plik.

Potwierdzenie negocjacji przed edycją

Zwiększ szczegółowość serwera i klienta i przeczytaj wiersz kanału sterującego, który OpenVPN wypisuje po połączeniu. Podaje wersję TLS i wynegocjowany szyfr oraz zgłasza typ klucza certyfikatu partnera. Ten jeden wiersz odpowiada na pytanie, które plik konfiguracji tylko sugeruje.

Jeśli pokazuje TLS 1.2 z zestawem ECDHE-RSA i certyfikatem RSA, kombinacja jest dokładnie tym, czego oczekuje dh none, i nie ma nic do naprawy. Jeśli pokazuje zestaw DHE lub niepowodzenie uzgadniania bez wspólnego szyfru, poprawka jest w polityce szyfrów lub możliwościach klienta, nie w certyfikacie.

Przetestuj najstarszego klienta, którego zamierzasz obsługiwać, ponieważ obecny klient może wynegocjować TLS 1.3, podczas gdy starszy jest ograniczony do zestawów TLS 1.2. Jeśli najstarszy klient nie ma żadnego pokrycia, rozszerz dozwolone zestawy lub zaktualizuj ten punkt końcowy.

Nie wyłączaj weryfikacji certyfikatów, aby obejść niepowodzenie uzgadniania. Niepowodzenie mówi ci, że strony nie mogły uzgodnić wymiany kluczy, a wyłączenie sprawdzania usuwa gwarancję tożsamości bez rozwiązania umowy.

Lista kontrolna: czy certyfikat to RSA, czy zestaw ECDHE jest dozwolony, czy log pokazuje ten zestaw i czy najstarszy obsługiwany klient też go negocjuje? Jeśli wszystkie cztery odpowiedzi brzmią tak, dh none robi swoje.