OpenVPN EC proti ED: zakaj ti imeni nista lestvica moči

Posamezno ec, ed, ecdh, ecdsa, auth in seznam šifer TLS postavite drug ob drugega v en profil in datoteka začne izgledati kot gumb moči s šestimi položaji. Pa ni. Vsako ime odgovarja na drugo vprašanje in dva profila, ki se razlikujeta v enem od njih, nista nujno močnejša ali šibkejša drug od drugega. Razvrščanje imen po delu, ki ga opravljajo, traja približno pet minut in prepreči večino slabih sprememb, ki jih ljudje naredijo v delujoči konfiguraciji.

Spodnje razvrščanje se začne pri sami zmedi in nato gre navzven, k delom profila, ki resnično odločajo, kaj ščiti vaš promet. Vsak razdelek po vrsti vzame eno napačno branje in pokaže, na kaj je ime v resnici privezano.

Dve črki, dve različni vprašanji

Par, ki povzroča največ razprav, sta EC in ED, razprava pa običajno predpostavlja, da gre za tekmovalna odgovora na eno vprašanje. Nista niti na isti osi. EC opisuje družino matematike: kriptografijo z eliptičnimi krivuljami, kjer varnost izvira iz težavnosti diskretnega logaritma na krivulji in ne v velikem končnem polju.

ED opisuje obliko krivulje znotraj te družine. Krivulje Twisted Edwards so predstavitev, izbrana zaradi hitrosti in zaradi odpornosti na več napak pri izvedbi, Ed25519 pa je ime, ki ga ljudje običajno mislijo. Krivulja ni tekmec kriptografiji z eliptičnimi krivuljami; je eden od načinov zapisa eliptične krivulje. Branje ED kot "novejši, močnejši EC" je prvi napačni ovinek in vse za njim je ponavadi napačno v isti smeri.

Podpisovanje in izmenjava sta ločeni nalogi

Ko je vprašanje družine rešeno, se preostala imena razdelijo v dva stolpca, ki se nikoli ne nadomeščata. En stolpec podpisuje, drugi se dogovori o skupni skrivnosti.

EdDSA in ECDSA oba podpisujeta, vendar gre za različni shemi z različnimi oblikami ključev, zato potrdila, izdanega za eno, ni mogoče uporabiti kot drugo. EdDSA je definirana za majhno množico krivulj; P-256 ni ena od njih, zato se potrdilo P-256 preverja z ECDSA in nikoli z Ed25519.

Stolpec izmenjave nima ustreznega poimenovanja EdDH. Efemerni dogovor na ključu Curve25519 je X25519, in to je ECDH z določeno krivuljo, natanko tako kot pri P-256. Ed25519 strogo pomeni shemo podpisa, čeprav se ime ohlapno uporablja tudi za izmenjavo, ker sta krivulji povezani: oblika Edwards za podpisovanje in oblika Montgomery za X25519 opisujeta isto osnovno grupo.

Zakaj profil EC nima datoteke dh

Datoteka dh vsebuje vnaprej ustvarjene parametre za Diffie-Hellman v končnem polju in ti parametri obstajajo zato, ker morata veliko praštevilo in generator od nekod priti. Izmenjava na eliptični krivulji ju ne potrebuje: imenovana krivulja je nabor parametrov in obe strani ju že poznata. To je ves razlog, zakaj lahko profil EC direktivo izpusti.

Dve situaciji še vedno ustvarita vrstico dh v profilu, ki je sicer videti sodoben. Prva je drugi poslušalec ali starejši partner, ki se resnično pogaja o skupinah končnega polja. Druga je preostalo besedilo, kopirano iz predloge iz obdobja RSA in nikoli odstranjeno. Profil, ki za izmenjavo navede krivuljo in še vedno naloži datoteko dh z 2048 biti, ni zato nič varnejši; nosi neuporabljen predmet.

TLS 1.3 je izmenjavo ključev umaknil iz imena

Primerjajte TLS_AES_256_GCM_SHA384 s TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 in krajše ime je videti kot znižanje. To je preimenovanje in razlog je strukturen: TLS 1.3 je odstranil statični RSA in izmenjavo ključev Diffie-Hellman v končnem polju, zato je efemerna izmenjava na eliptični krivulji edina preostala možnost brez PSK. Če bi jo poimenovali v vsakem naboru, bi ponovili isto dejstvo ducatkrat.

Vrsta potrdila je iz imena izginila iz povezanega razloga. V 1.3 potrdilo preverja podpis rokovanja, ne dogovora o ključu, zato ne izbira več nabora. Zato je v konfiguraciji ločen seznam šifer za 1.3: nabori so bili preimenovani in preurejeni, ne oslabljeni.

Ena posledica je vredna jasne besede. ECDHE je algoritem za izmenjavo ključev in nikoli šifra. Nabor, opisan kot "eliptičen", pove nekaj o tem, kako sta strani prišli do skupnega ključa, in nič o tem, kaj nato šifrira koristni tovor.

auth preverja pakete, ne koristnega tovora

Direktiva auth izbere povzetek HMAC, ki preverja pakete, njena zgodovinska privzeta vrednost pa je SHA1. Pri šifri podatkov, ki ni AEAD, OpenVPN izračuna povzetek čez šifrirano besedilo in ga pripne, to je postavitev "šifriraj, nato MAC", ki naredi manipulacijo z zapolnitvijo nepraktično.

Mit tukaj je, da zvišanje auth na SHA512 utrdi tunel. Ne poveča moči šifriranja, in če je dogovorjena šifra podatkov način AEAD, kot je AES-256-GCM, se povzetek sploh ne uporabi na podatkovnih paketih. Oznaka GCM jih že preverja, vrednost auth pa ostane za HMAC krmilnega kanala in za vsako šifro brez AEAD, ki se še uporablja.

Direktiva je torej pomembna, a pomembna na ožjem mestu, kot nakazuje njen položaj v datoteki. Preverjanje, katera šifra je bila dejansko dogovorjena, vam pove, ali se sploh uporablja.

Profil berite po stolpcu, ne po rangu

Tri vprašanja čisto ločijo plasti in na vsako odgovori drug del dogovorjene seje. Katera šifra ščiti koristni tovor? Katera oznaka ali povzetek jamči za vsak paket in ali uporabljena šifra to sploh potrebuje? Čigavo potrdilo je zaprlo rokovanje in ali je krmilni kanal dodatno zaščiten z tls-auth ali tls-crypt?

Nič v oznaki EC ali ED ne odloči nobenega od teh treh, tudi ime nabora samo po sebi ne odloči nobenega od njih. Dogovorjeni rezultat je edini dokaz, zato ga berite, namesto da bi moč sklepali iz besedišča:

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

Prvi ukaz vam pove, katero shemo podpisa vaše potrdilo dejansko uporablja, in to je edini zanesljiv način, da veste, ali tečete na ECDSA ali Ed25519. Drugi prikaže vrstico krmilnega kanala, ki jo je odjemalec zabeležil za sejo, vključno z različico TLS in naborom, na katerem se je ustavil. Če spremembe profila ni mogoče utemeljiti z enim od teh dveh izhodov, gre verjetno za spremembo imena in ne lastnosti.