OpenVPN EC ir ED: kodėl šie pavadinimai nėra stiprumo kopėčios
EC, ED, ECDHE ir auth atsako į skirtingus klausimus. Prieš ką nors lygindami ar redaguodami, surikiuokite OpenVPN profilį pagal darbą, kurį atlieka kiekvienas pavadinimas.
Įdėkite ec, ed, ecdh, ecdsa, auth ir TLS šifrų sąrašą greta viename profilyje, ir failas pradeda atrodyti kaip šešių padėčių stiprumo reguliatorius. Bet jis toks nėra. Kiekvienas pavadinimas atsako į kitą klausimą, o du profiliai, besiskiriantys vienu iš jų, nebūtinai yra stipresni ar silpnesni už kitą. Pavadinimų surikiavimas pagal atliekamą darbą užtrunka apie penkias minutes ir užkerta kelią daugumai blogų pakeitimų, kuriuos žmonės daro veikiančioje konfigūracijoje.
Toliau pateiktas rikiavimas prasideda nuo paties sumišimo ir tada juda į išorę, prie tų profilio dalių, kurios iš tikrųjų nulemia, kas apsaugo jūsų srautą. Kiekvienas skyrius paeiliui paima vieną klaidingą skaitymą ir parodo, prie ko pavadinimas iš tiesų prijungtas.
Dvi raidės, du skirtingi klausimai
Labiausiai ginčų kelianti pora yra EC ir ED, o ginčas paprastai daro prielaidą, kad tai konkuruojantys atsakymai į vieną klausimą. Jie net nėra toje pačioje ašyje. EC apibūdina matematikos šeimą: elipsinių kreivių kriptografiją, kur saugumas kyla iš diskretinio logaritmo kreivėje sunkumo, o ne dideliame baigtiniame kūne.
ED apibūdina kreivės formą toje šeimoje. Twisted Edwards kreivės yra atvaizdavimas, pasirinktas dėl greičio ir atsparumo kelioms įgyvendinimo klaidoms, o Ed25519 yra vardas, kurį žmonės paprastai turi omenyje. Kreivė nėra elipsinių kreivių kriptografijos konkurentė; tai vienas iš būdų užrašyti elipsinę kreivę. ED skaitymas kaip "naujesnio, stipresnio EC" yra pirmas klaidingas posūkis, o viskas po jo paprastai būna klaidinga ta pačia kryptimi.
Pasirašymas ir mainai yra atskiri darbai
Kai šeimos klausimas išspręstas, likę pavadinimai susiskirsto į du stulpelius, kurie niekada nepakeičia vienas kito. Vienas stulpelis pasirašo, kitas susitaria dėl bendros paslapties.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
Ir EdDSA, ir ECDSA pasirašo, tačiau tai skirtingos schemos su skirtingais raktų formatais, todėl vienam išduotas sertifikatas negali būti naudojamas kaip kitas. EdDSA apibrėžta nedidelei kreivių aibei; P-256 nėra viena iš jų, todėl P-256 sertifikatas tikrinamas su ECDSA ir niekada su Ed25519.
Mainų stulpelyje nėra atitikmens, vadinamo EdDH. Efemeriškas susitarimas dėl Curve25519 rakto yra X25519, ir tai yra ECDH su konkrečia kreive, lygiai taip pat kaip su P-256. Ed25519 griežtai reiškia parašo schemą, nors vardas laisvai vartojamas ir mainams, nes dvi kreivės yra susijusios: pasirašymui naudojama Edwards forma ir X25519 naudojama Montgomery forma apibūdina tą pačią pagrindinę grupę.
Kodėl EC profilyje nėra dh failo
dh faile yra iš anksto sugeneruoti baigtinio kūno Diffie-Hellman parametrai, ir tie parametrai egzistuoja todėl, kad didelis pirminis skaičius ir generatorius turi iš kažkur atsirasti. Elipsinės kreivės mainams jų nereikia: įvardyta kreivė yra parametrų rinkinys, ir abi pusės jį jau žino. Tai yra visa priežastis, kodėl EC profilis gali praleisti direktyvą.
Dvi situacijos vis dar sukuria dh eilutę profilyje, kuris kitu atžvilgiu atrodo modernus. Pirmoji yra antras klausytojas arba senesnis partneris, kuris iš tikrųjų derasi dėl baigtinio kūno grupių. Antroji yra likęs tekstas, nukopijuotas iš RSA eros šablono ir niekada nepašalintas. Profilis, kuris mainams įvardija kreivę ir vis dar įkelia 2048 bitų dh failą, nėra saugesnis dėl to, kad taip padarė; jis nešiojasi nenaudojamą artefaktą.
TLS 1.3 pašalino raktų mainus iš pavadinimo
Palyginkite TLS_AES_256_GCM_SHA384 su TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 ir trumpesnis pavadinimas atrodo kaip sumažinimas. Tai pervadinimas, o priežastis yra struktūrinė: TLS 1.3 pašalino statinį RSA ir baigtinio kūno Diffie-Hellman raktų mainus, todėl efemeriški elipsinės kreivės mainai yra vienintelė likusi ne PSK parinktis. Įvardijimas kiekviename rinkinyje kartotų tą patį faktą tuziną kartų.
Sertifikato tipas iš pavadinimo dingo dėl susijusios priežasties. 1.3 versijoje sertifikatas autentifikuoja rankos paspaudimo parašą, o ne raktų susitarimą, todėl jis nebe pasirenka rinkinio. Štai kodėl konfigūracijoje yra atskiras 1.3 šifrų sąrašas: rinkiniai buvo pervardyti ir pertvarkyti, o ne susilpninti.
Vieną pasekmę verta pasakyti tiesiogiai. ECDHE yra raktų mainų algoritmas ir niekada ne šifras. Rinkinys, apibūdinamas kaip "elipsinis", pasako kai ką apie tai, kaip dvi pusės priėjo prie bendro rakto, ir nieko apie tai, kas paskui šifruoja naudingąją apkrovą.
auth autentifikuoja paketus, o ne naudingąją apkrovą
Direktyva auth pasirenka HMAC santrauką, kuri autentifikuoja paketus, o jos istorinė numatytoji reikšmė yra SHA1. Su ne AEAD duomenų šifru OpenVPN apskaičiuoja santrauką iš šifruoto teksto ir ją prideda, tai šifruok-tada-MAC tvarka, dėl kurios manipuliavimas užpildu tampa nepraktiškas.
Mitas čia yra tas, kad auth pakėlimas iki SHA512 sukietina tunelį. Tai nedidina šifravimo stiprumo, o jei suderėtas duomenų šifras yra AEAD režimas, pavyzdžiui, AES-256-GCM, santrauka duomenų paketams visai netaikoma. GCM žyma juos jau autentifikuoja, o auth reikšmė lieka valdymo kanalo HMAC ir bet kuriam dar naudojamam ne AEAD šifrui.
Taigi direktyva svarbi, bet svarbi siauresnėje vietoje, nei rodo jos padėtis faile. Patikrinimas, koks šifras iš tikrųjų buvo suderėtas, pasako, ar ji apskritai taikoma.
Skaitykite profilį pagal stulpelį, o ne pagal rangą
Trys klausimai švariai atskiria sluoksnius, ir į kiekvieną atsako skirtinga suderėtos sesijos dalis. Kuris šifras apsaugo naudingąją apkrovą? Kuri žyma ar santrauka garantuoja kiekvieną paketą, ir ar naudojamam šifrui jos apskritai reikia? Kieno sertifikatas uždarė rankos paspaudimą, ir ar valdymo kanalas papildomai apsaugotas tls-auth ar tls-crypt?
Niekas EC ar ED žymoje neišsprendžia nė vieno iš tų trijų, o rinkinio pavadinimas pats savaime taip pat neišsprendžia nė vieno jų. Suderėtas rezultatas yra vienintelis įrodymas, todėl skaitykite jį, o ne spėliokite stiprumą iš žodyno:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logPirmoji komanda pasako, kurią parašo schemą jūsų sertifikatas iš tikrųjų naudoja, ir tai vienintelis patikimas būdas sužinoti, ar dirbate su ECDSA, ar su Ed25519. Antroji parodo valdymo kanalo eilutę, kurią klientas įrašė sesijai, įskaitant TLS versiją ir rinkinį, ties kuriuo ji sustojo. Jei profilio pakeitimo negalima pagrįsti vienu iš šių dviejų išvedimų, tai greičiausiai pavadinimo, o ne savybės pakeitimas.