OpenVPN EC vs ED: proč tyto názvy nejsou žebříkem síly

Dejte ec, ed, ecdh, ecdsa, auth a seznam šifer TLS vedle sebe do jednoho profilu a soubor začne vypadat jako volič síly se šesti polohami. Není. Každý název odpovídá na jinou otázku a dva profily, které se liší v jednom z nich, nejsou nutně silnější ani slabší než druhý. Setřídění názvů podle práce, kterou dělají, zabere asi pět minut a zabrání většině špatných úprav, které lidé dělají na fungující konfiguraci.

Následující třídění začíná u samotného zmatku a potom jde směrem ven k částem profilu, které skutečně rozhodují o tom, co chrání váš provoz. Každá část postupně bere jedno chybné čtení a ukazuje, k čemu je název doopravdy připoutaný.

Dvě písmena, dvě různé otázky

Dvojice, která vyvolává nejvíc sporů, je EC a ED, a spor obvykle předpokládá, že jde o soupeřící odpovědi na jednu otázku. Ani nejsou na stejné ose. EC popisuje rodinu matematiky: kryptografii na eliptických křivkách, kde bezpečnost pochází z obtížnosti diskrétního logaritmu na křivce, a ne ve velkém konečném tělese.

ED popisuje tvar křivky uvnitř této rodiny. Křivky Twisted Edwards jsou reprezentace zvolená kvůli rychlosti a odolnosti vůči několika chybám implementace a Ed25519 je název, který lidé obvykle míní. Křivka není konkurentem kryptografie na eliptických křivkách; je jedním ze způsobů zápisu eliptické křivky. Číst ED jako „novější, silnější EC“ je první špatné odbočení a všechno po něm bývá špatně stejným směrem.

Podepisování a výměna jsou oddělené úlohy

Jakmile je otázka rodiny vyřešena, zbývající názvy se rozdělí do dvou sloupců, které se nikdy nezastupují. Jeden sloupec podepisuje, druhý se dohaduje na sdíleném tajemství.

EdDSA i ECDSA podepisují, ale jsou to různá schémata s různými formáty klíčů, takže certifikát vystavený pro jednoho nelze použít jako druhý. EdDSA je definováno pro malou množinu křivek; P-256 mezi ně nepatří, a proto se certifikát P-256 ověřuje pomocí ECDSA a nikdy pomocí Ed25519.

Sloupec výměny nemá ekvivalent jménem EdDH. Efemérní dohoda na klíči Curve25519 je X25519 a to je ECDH s konkrétní křivkou, přesně jako u P-256. Ed25519 striktně označuje schéma podpisu, i když se název volně používá pro výměnu, protože obě křivky spolu souvisí: tvar Edwards používaný k podpisu a tvar Montgomery používaný pro X25519 popisují stejnou podkladovou grupu.

Proč profil EC nemá soubor dh

Soubor dh obsahuje předem vygenerované parametry pro Diffie-Hellman v konečném tělese a tyto parametry existují proto, že velké prvočíslo a generátor musí odněkud přijít. Výměna na eliptické křivce je nepotřebuje: pojmenovaná křivka je množina parametrů a obě strany ji už znají. To je celý důvod, proč může profil EC direktivu vynechat.

Dvě situace přesto vytvářejí řádek dh v profilu, který jinak vypadá moderně. První je druhý posluchač nebo starší protějšek, který skutečně vyjednává grupy konečného tělesa. Druhá je zbytkový text zkopírovaný ze šablony z éry RSA a nikdy neodstraněný. Profil, který pro výměnu pojmenuje křivku a přesto načítá 2048bitový soubor dh, není bezpečnější proto, že to udělal; nese nevyužitý artefakt.

TLS 1.3 odstranil výměnu klíčů z názvu

Porovnejte TLS_AES_256_GCM_SHA384 s TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 a kratší název vypadá jako downgrade. Je to přejmenování a důvod je strukturální: TLS 1.3 odstranil statický RSA a výměnu klíčů Diffie-Hellman v konečném tělese, takže efemérní výměna na eliptické křivce je jediná zbývající možnost bez PSK. Pojmenovat ji v každé sadě by znamenalo zopakovat stejný fakt dvanáctkrát.

Typ certifikátu zmizel z názvu ze souvisejícího důvodu. V 1.3 certifikát ověřuje podpis handshake, ne dohodu o klíči, takže už nevybírá sadu. Právě proto v konfiguraci existuje samostatný seznam šifer pro 1.3: sady byly přejmenovány a přeorganizovány, ne oslabeny.

Jeden důsledek stojí za to říct přímo. ECDHE je algoritmus výměny klíčů a nikdy šifra. Sada popsaná jako „eliptická“ říká něco o tom, jak obě strany dospěly ke sdílenému klíči, a nic o tom, co pak šifruje užitečné zatížení.

auth ověřuje pakety, ne užitečné zatížení

Direktiva auth vybírá HMAC otisk, který ověřuje pakety, a jejím historickým výchozím nastavením je SHA1. U šifry dat, která není AEAD, OpenVPN počítá otisk přes šifrovaný text a připojuje ho, tedy uspořádání „zašifruj, potom MAC“, které dělá manipulaci s výplní nepraktickou.

Mýtus tady je, že zvýšení auth na SHA512 zpevní tunel. Nezvyšuje sílu šifrování, a pokud je vyjednaná šifra dat režim AEAD jako AES-256-GCM, otisk se na datové pakety vůbec neaplikuje. Značka GCM je už ověřuje a hodnota auth zůstává pro HMAC řídicího kanálu a pro každou šifru, která není AEAD a dosud se používá.

Direktiva tedy záleží, ale záleží na užším místě, než naznačuje její pozice v souboru. Kontrola, která šifra byla skutečně vyjednána, vám řekne, zda se vůbec uplatní.

Čtěte profil po sloupcích, ne po pořadí

Tři otázky čistě oddělují vrstvy a na každou odpovídá jiná část vyjednané relace. Která šifra chrání užitečné zatížení? Která značka nebo otisk ručí za každý paket a vyžaduje jej vůbec použitá šifra? Čí certifikát uzavřel handshake a je řídicí kanál navíc chráněn pomocí tls-auth nebo tls-crypt?

Nic v označení EC nebo ED nerozhoduje žádnou z těch tří otázek a samotný název sady také nerozhoduje žádnou z nich. Vyjednaný výsledek je jediný důkaz, takže čtěte jej, místo abyste sílu odvozovali ze slovníku:

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

První příkaz vám řekne, které schéma podpisu váš certifikát skutečně používá, což je jediný spolehlivý způsob, jak zjistit, zda běžíte na ECDSA, nebo Ed25519. Druhý ukazuje řádek řídicího kanálu, který klient pro relaci zaznamenal, včetně verze TLS a sady, na které se ustálil. Pokud úpravu profilu nelze odůvodnit jedním z těchto dvou výstupů, je to pravděpodobně změna názvu, a ne vlastnosti.