OpenVPN EC vs ED: dlaczego te nazwy nie są drabiną siły

Umieść ec, ed, ecdh, ecdsa, auth i listę szyfrów TLS obok siebie w jednym profilu, a plik zaczyna wyglądać jak pokrętło siły z sześcioma pozycjami. Ale nim nie jest. Każda nazwa odpowiada na inne pytanie, a dwa profile różniące się w jednej z nich nie są przez to silniejsze ani słabsze od siebie. Posortowanie nazw według pracy, którą wykonują, zajmuje około pięciu minut i zapobiega większości złych zmian, które ludzie robią w działającej konfiguracji.

Poniższe uporządkowanie zaczyna się od samego zamieszania, a potem przechodzi na zewnątrz, do tych części profilu, które naprawdę decydują, co chroni twój ruch. Każda sekcja po kolei bierze jedno błędne odczytanie i pokazuje, do czego nazwa jest naprawdę przywiązana.

Dwie litery, dwa różne pytania

Para, która wywołuje najwięcej sporów, to EC i ED, a spór zwykle zakłada, że są to konkurencyjne odpowiedzi na jedno pytanie. Nie leżą nawet na tej samej osi. EC opisuje rodzinę matematyki: kryptografię krzywych eliptycznych, w której bezpieczeństwo pochodzi z trudności logarytmu dyskretnego na krzywej, a nie w dużym ciele skończonym.

ED opisuje kształt krzywej wewnątrz tej rodziny. Krzywe Twisted Edwards to reprezentacja wybrana ze względu na szybkość i odporność na kilka błędów implementacji, a Ed25519 to nazwa, którą ludzie zwykle mają na myśli. Krzywa nie jest konkurentem kryptografii krzywych eliptycznych; to jeden ze sposobów zapisania krzywej eliptycznej. Czytanie ED jako "nowszego, silniejszego EC" to pierwszy zły zakręt, a wszystko po nim zwykle jest błędne w tym samym kierunku.

Podpisywanie i wymiana to osobne zadania

Gdy kwestia rodziny jest rozstrzygnięta, pozostałe nazwy dzielą się na dwie kolumny, które nigdy się nie zastępują. Jedna kolumna podpisuje, druga uzgadnia wspólny sekret.

EdDSA i ECDSA oba podpisują, ale to różne schematy z różnymi formatami kluczy, więc certyfikat wystawiony dla jednego nie jest użyteczny jako drugi. EdDSA jest zdefiniowany dla niewielkiego zbioru krzywych; P-256 nie jest jedną z nich, dlatego certyfikat P-256 weryfikuje się za pomocą ECDSA i nigdy za pomocą Ed25519.

Kolumna wymiany nie ma odpowiednika o nazwie EdDH. Efemeryczne uzgodnienie na kluczu Curve25519 to X25519, a to jest ECDH z konkretną krzywą, dokładnie tak jak z P-256. Ed25519 ściśle oznacza schemat podpisu, choć nazwa jest luźno używana do wymiany, ponieważ obie krzywe są powiązane: forma Edwards używana do podpisywania i forma Montgomery używana dla X25519 opisują tę samą grupę bazową.

Dlaczego profil EC nie ma pliku dh

Plik dh zawiera wygenerowane wcześniej parametry dla Diffie-Hellmana w ciele skończonym, a te parametry istnieją, ponieważ duża liczba pierwsza i generator muszą skądś pochodzić. Wymiana na krzywej eliptycznej ich nie potrzebuje: nazwana krzywa jest zbiorem parametrów, a obie strony już ją znają. To cały powód, dla którego profil EC może pominąć tę dyrektywę.

Dwie sytuacje nadal tworzą wiersz dh w profilu, który poza tym wygląda nowocześnie. Pierwsza to drugi nasłuchujący albo starszy partner, który naprawdę negocjuje grupy ciała skończonego. Druga to pozostały tekst skopiowany ze szablonu z ery RSA i nigdy nieusunięty. Profil, który nazywa krzywą do wymiany i nadal ładuje plik dh o długości 2048 bitów, nie jest przez to bezpieczniejszy; niesie nieużywany artefakt.

TLS 1.3 usunął wymianę kluczy z nazwy

Porównaj TLS_AES_256_GCM_SHA384 z TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, a krótsza nazwa wygląda jak degradacja. To zmiana nazwy, a powód jest strukturalny: TLS 1.3 usunął statyczny RSA i wymianę kluczy Diffie-Hellmana w ciele skończonym, więc efemeryczna wymiana na krzywej eliptycznej jest jedyną pozostałą opcją bez PSK. Nazywanie jej w każdym zestawie powtarzałoby ten sam fakt tuzin razy.

Typ certyfikatu zniknął z nazwy z pokrewnego powodu. W wersji 1.3 certyfikat uwierzytelnia podpis uścisku dłoni, a nie uzgodnienie klucza, więc nie wybiera już zestawu. Dlatego w konfiguracji istnieje osobna lista szyfrów dla 1.3: zestawy zostały przemianowane i uporządkowane na nowo, a nie osłabione.

Jedna konsekwencja zasługuje na powiedzenie wprost. ECDHE jest algorytmem wymiany kluczy i nigdy szyfrem. Zestaw opisywany jako "eliptyczny" mówi coś o tym, jak dwie strony doszły do wspólnego klucza, i nic o tym, co potem szyfruje ładunek.

auth uwierzytelnia pakiety, a nie ładunki

Dyrektywa auth wybiera skrót HMAC, który uwierzytelnia pakiety, a jej historyczną wartością domyślną jest SHA1. Przy szyfrze danych, który nie jest AEAD, OpenVPN oblicza skrót z szyfrogramu i dołącza go, czyli układ zaszyfruj-potem-MAC, który czyni manipulowanie dopełnieniem niepraktycznym.

Mit polega tu na tym, że podniesienie auth do SHA512 utwardza tunel. To nie zwiększa siły szyfrowania, a jeśli wynegocjowany szyfr danych jest trybem AEAD, takim jak AES-256-GCM, skrót w ogóle nie jest stosowany do pakietów danych. Znacznik GCM już je uwierzytelnia, a wartość auth zostaje dla HMAC kanału sterującego i dla każdego szyfru bez AEAD, który nadal jest używany.

Dyrektywa ma więc znaczenie, ale ma je w węższym miejscu, niż sugeruje jej pozycja w pliku. Sprawdzenie, który szyfr faktycznie wynegocjowano, mówi, czy w ogóle ma zastosowanie.

Czytaj profil po kolumnie, a nie po randze

Trzy pytania czysto rozdzielają warstwy, a na każde odpowiada inna część wynegocjowanej sesji. Który szyfr chroni ładunek? Który znacznik lub skrót poręcza za każdy pakiet i czy używany szyfr w ogóle go wymaga? Czyj certyfikat zamknął uścisk dłoni i czy kanał sterujący jest dodatkowo chroniony przez tls-auth lub tls-crypt?

Nic w etykiecie EC ani ED nie rozstrzyga żadnego z tych trzech, a nazwa zestawu sama nie rozstrzyga żadnego z nich. Wynegocjowany wynik jest jedynym dowodem, więc czytaj go, zamiast wnioskować o sile ze słownika:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Pierwsze polecenie mówi, jakiego schematu podpisu naprawdę używa twój certyfikat, i to jedyny pewny sposób, by wiedzieć, czy działasz na ECDSA, czy na Ed25519. Drugie pokazuje wiersz kanału sterującego, który klient zapisał dla sesji, wraz z wersją TLS i zestawem, na którym się zatrzymał. Jeśli zmiany w profilu nie da się uzasadnić jednym z tych dwóch wyników, to prawdopodobnie zmiana nazwy, a nie właściwości.