OpenVPN EC vs ED: prečo tieto názvy nie sú rebríkom sily

Dajte ec, ed, ecdh, ecdsa, auth a zoznam šifier TLS vedľa seba do jedného profilu a súbor začne vyzerať ako volič sily so šiestimi polohami. Ale nie je. Každý názov odpovedá na inú otázku a dva profily, ktoré sa líšia v jednom z nich, nie sú nutne silnejšie ani slabšie jeden ako druhý. Zoradenie názvov podľa práce, ktorú vykonávajú, zaberie asi päť minút a zabráni väčšine zlých úprav, ktoré ľudia robia na fungujúcej konfigurácii.

Nasledujúce triedenie začína pri samotnom zmätku a potom ide smerom von k častiam profilu, ktoré skutočne rozhodujú o tom, čo chráni vašu prevádzku. Každá časť postupne berie jedno nesprávne čítanie a ukazuje, k čomu je názov naozaj pripútaný.

Dve písmená, dve rôzne otázky

Dvojica, ktorá vyvoláva najviac sporov, je EC a ED, a spor zvyčajne predpokladá, že ide o súperiace odpovede na jednu otázku. Nie sú ani na tej istej osi. EC opisuje rodinu matematiky: kryptografiu na eliptických krivkách, kde bezpečnosť pochádza z obtiažnosti diskrétneho logaritmu na krivke, a nie vo veľkom konečnom poli.

ED opisuje tvar krivky vnútri tejto rodiny. Krivky Twisted Edwards sú reprezentácia zvolená pre rýchlosť a pre odolnosť voči niekoľkým chybám implementácie a Ed25519 je názov, ktorý ľudia zvyčajne myslia. Krivka nie je konkurentom kryptografie na eliptických krivkách; je jedným zo spôsobov zápisu eliptickej krivky. Čítať ED ako „novšie, silnejšie EC“ je prvá nesprávna odbočka a všetko po nej býva nesprávne rovnakým smerom.

Podpisovanie a výmena sú oddelené úlohy

Keď je otázka rodiny vyriešená, zostávajúce názvy sa rozdelia do dvoch stĺpcov, ktoré sa nikdy nenahrádzajú. Jeden stĺpec podpisuje, druhý sa dohodne na spoločnom tajomstve.

EdDSA aj ECDSA podpisujú, ale sú to rôzne schémy s rôznymi formátmi kľúčov, takže certifikát vydaný pre jednu nemožno použiť ako druhý. EdDSA je definovaná pre malú množinu kriviek; P-256 medzi ne nepatrí, preto sa certifikát P-256 overuje pomocou ECDSA a nikdy pomocou Ed25519.

Stĺpec výmeny nemá ekvivalent s názvom EdDH. Efemérna dohoda na kľúči Curve25519 je X25519 a to je ECDH s konkrétnou krivkou, presne ako pri P-256. Ed25519 striktne označuje schému podpisu, hoci sa názov voľne používa aj pre výmenu, pretože obe krivky súvisia: tvar Edwards používaný na podpis a tvar Montgomery používaný pre X25519 opisujú tú istú základnú grupu.

Prečo profil EC nemá súbor dh

Súbor dh obsahuje vopred vygenerované parametre pre Diffie-Hellman v konečnom poli a tieto parametre existujú preto, lebo veľké prvočíslo a generátor musia odniekiaľ prísť. Výmena na eliptickej krivke ich nepotrebuje: pomenovaná krivka je množina parametrov a obe strany ju už poznajú. To je celý dôvod, prečo môže profil EC direktívu vynechať.

Dve situácie stále vytvárajú riadok dh v profile, ktorý inak vyzerá moderne. Prvá je druhý poslucháč alebo starší partner, ktorý skutočne vyjednáva grupy konečného poľa. Druhá je zvyškový text skopírovaný zo šablóny z éry RSA a nikdy neodstránený. Profil, ktorý pomenuje krivku pre výmenu a stále načítava 2048-bitový súbor dh, nie je preto bezpečnejší; nesie nepoužitý artefakt.

TLS 1.3 odstránil výmenu kľúčov z názvu

Porovnajte TLS_AES_256_GCM_SHA384 s TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 a kratší názov vyzerá ako zníženie. Je to premenovanie a dôvod je štrukturálny: TLS 1.3 odstránil statické RSA a výmenu kľúčov Diffie-Hellman v konečnom poli, takže efemérna výmena na eliptickej krivke je jediná zostávajúca možnosť bez PSK. Pomenovať ju v každej sade by znamenalo zopakovať ten istý fakt tucetkrát.

Typ certifikátu zmizol z názvu zo súvisiaceho dôvodu. V 1.3 certifikát overuje podpis podania ruky, nie dohodu o kľúči, takže už nevyberá sadu. Preto v konfigurácii existuje samostatný zoznam šifier pre 1.3: sady boli premenované a preorganizované, nie oslabené.

Jeden dôsledok stojí za to povedať priamo. ECDHE je algoritmus výmeny kľúčov a nikdy šifra. Sada opísaná ako „eliptická“ hovorí niečo o tom, ako sa obe strany dostali k spoločnému kľúču, a nič o tom, čo potom šifruje užitočné zaťaženie.

auth overuje pakety, nie užitočné zaťaženie

Direktíva auth vyberá HMAC odtlačok, ktorý overuje pakety, a jej historickou predvolenou hodnotou je SHA1. Pri šifre údajov, ktorá nie je AEAD, OpenVPN vypočíta odtlačok cez šifrovaný text a pripojí ho, teda usporiadanie „zašifruj, potom MAC“, ktoré robí manipuláciu s výplňou nepraktickou.

Mýtus je tu ten, že zvýšenie auth na SHA512 spevní tunel. Nezvyšuje silu šifrovania, a ak je vyjednaná šifra údajov režim AEAD ako AES-256-GCM, odtlačok sa na dátové pakety vôbec neaplikuje. Značka GCM ich už overuje a hodnota auth zostáva pre HMAC riadiaceho kanála a pre každú šifru, ktorá nie je AEAD a ešte sa používa.

Direktíva teda záleží, ale záleží na užšom mieste, než naznačuje jej pozícia v súbore. Kontrola, ktorá šifra bola skutočne vyjednaná, vám povie, či sa vôbec uplatní.

Čítajte profil po stĺpcoch, nie po poradí

Tri otázky čisto oddeľujú vrstvy a na každú odpovedá iná časť vyjednanej relácie. Ktorá šifra chráni užitočné zaťaženie? Ktorá značka alebo odtlačok ručí za každý paket a vyžaduje ju použitá šifra vôbec? Ktorý certifikát uzavrel podanie ruky a je riadiaci kanál navyše chránený pomocou tls-auth alebo tls-crypt?

Nič v označení EC alebo ED nerozhoduje ani jednu z tých troch a samotný názov sady tiež nerozhoduje ani jednu z nich. Vyjednaný výsledok je jediný dôkaz, takže čítajte ho, namiesto odvodzovania sily zo slovníka:

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

Prvý príkaz vám povie, ktorú schému podpisu váš certifikát skutočne používa, a to je jediný spoľahlivý spôsob, ako zistiť, či bežíte na ECDSA alebo Ed25519. Druhý zobrazuje riadok riadiaceho kanála, ktorý klient zaznamenal pre reláciu, vrátane verzie TLS a sady, na ktorej sa ustálil. Ak sa úprava profilu nedá odôvodniť jedným z týchto dvoch výstupov, je to pravdepodobne zmena názvu a nie vlastnosti.