OpenVPN EC vs ED: miks need nimed ei ole tugevusredel
EC, ED, ECDHE ja auth vastavad erinevatele küsimustele. Sorteerige OpenVPN-i profiil iga nime töö järgi, enne kui midagi võrdlete või muudate.
Pange ec, ed, ecdh, ecdsa, auth ja TLS-šifrite loend ühte profiili kõrvuti ja fail hakkab välja nägema nagu kuue asendiga tugevusnupp. Aga ei ole. Iga nimi vastab erinevale küsimusele ja kaks profiili, mis erinevad ühes neist, ei ole tingimata teineteisest tugevamad või nõrgemad. Nimetuste sorteerimine nende töö järgi võtab umbes viis minutit ja hoiab ära enamiku halbadest muudatustest, mida inimesed töötavas konfiguratsioonis teevad.
Järgnev sorteerimine algab segadusest endast ja liigub seejärel väljapoole, profiili nende osade juurde, mis tegelikult otsustavad, mis teie liiklust kaitseb. Iga jaotis võtab kordamööda ühe vale lugemise ja näitab, mille külge nimi tegelikult kinnitub.
Kaks tähte, kaks erinevat küsimust
Kõige rohkem vaidlusi tekitav paar on EC ja ED ning vaidlus eeldab tavaliselt, et need on ühele küsimusele võistlevad vastused. Need ei ole isegi samal teljel. EC kirjeldab matemaatikafamilja: elliptiliste kõverate krüptograafia, kus turvalisus tuleneb diskreetse logaritmi raskusest kõveral, mitte suures lõplikus korpuses.
ED kirjeldab kõvera kuju selle perekonna sees. Twisted Edwardsi kõverad on esitus, mis on valitud kiiruse ja mitme rakendusvea vastupidavuse tõttu, ning Ed25519 on nimi, mida inimesed tavaliselt mõtlevad. Kõver ei ole elliptiliste kõverate krüptograafia konkurent; see on üks viis elliptilise kõvera kirjutamiseks. ED lugemine kui „uuem, tugevam EC“ on esimene vale pööre ja kõik pärast seda kaldub olema vales samas suunas.
Allkirjastamine ja vahetamine on eraldi tööd
Kui perekonna küsimus on lahendatud, jagunevad ülejäänud nimed kahte veergu, mis ei asenda kunagi teineteist. Üks veerg allkirjastab, teine lepib kokku ühise saladuse.
| 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 |
Nii EdDSA kui ECDSA allkirjastavad, kuid need on erinevad skeemid erinevate võtmevormingutega, seega ühe jaoks välja antud sertifikaati ei saa kasutada teise jaoks. EdDSA on määratletud väikese kõverate hulga jaoks; P-256 ei ole üks neist, mistõttu P-256 sertifikaat kontrollitakse ECDSA-ga ja mitte kunagi Ed25519-ga.
Vahetuseveerul ei ole EdDH nimelist vastet. Efemeerne kokkulepe Curve25519 võtmel on X25519 ja see on ECDH kindla kõveraga, täpselt nagu P-256 puhul. Ed25519 tähendab rangelt allkirjaskeemi, kuigi nime kasutatakse vahetuse jaoks lõdvalt, sest kaks kõverat on seotud: allkirjastamiseks kasutatav Edwardsi kuju ja X25519 jaoks kasutatav Montgomery kuju kirjeldavad sama alusgruppi.
Miks EC-profiilis dh-faili pole
Fail dh sisaldab eelnevalt genereeritud parameetreid lõpliku korpuse Diffie-Hellmani jaoks ja need parameetrid on olemas, sest suur algarv ja generaator peavad kuskilt tulema. Elliptilise kõvera vahetus ei vaja neid: nimetatud kõver on parameetrite hulk ja mõlemad pooled teavad seda juba. See on kogu põhjus, miks EC-profiil võib direktiivi ära jätta.
Kaks olukorda tekitavad ikka dh rea profiilis, mis muidu näeb moodne välja. Esimene on teine kuulaja või vanem partner, kes tõesti läbiräägib lõpliku korpuse gruppe. Teine on ülejäänud tekst, mis on kopeeritud RSA-aegsest mallist ja mida pole kunagi eemaldatud. Profiil, mis nimetab vahetuse jaoks kõvera ja laadib siiski 2048-bitise dh-faili, ei ole seetõttu turvalisem; ta kannab kasutamata artefakti.
TLS 1.3 eemaldas võtmevahetuse nimest
Võrrelge TLS_AES_256_GCM_SHA384 ja TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 ning lühem nimi tundub allapoole minekuna. See on ümbernimetamine ja põhjus on struktuurne: TLS 1.3 eemaldas staatilise RSA ja lõpliku korpuse Diffie-Hellmani võtmevahetuse, seega efemeerne elliptilise kõvera vahetus on ainus allesjäänud mitte-PSK valik. Selle nimetamine igas komplektis kordaks sama fakti tosin korda.
Sertifikaadi tüüp kadus nimest seotud põhjusel. Versioonis 1.3 autendib sertifikaat käepigistuse allkirja, mitte võtmekokkulepet, seega ei vali see enam komplekti. Just seetõttu on konfiguratsioonis 1.3 jaoks eraldi šifriloend: komplektid nimetati ümber ja korraldati ümber, mitte ei nõrgestatud.
Üks tagajärg tasub otse välja öelda. ECDHE on võtmevahetusalgoritm ja mitte kunagi šifer. Komplekti kirjeldamine „elliptilisena“ ütleb midagi selle kohta, kuidas kaks partnerit jõudsid ühise võtmeni, ja mitte midagi selle kohta, mis seejärel kandevõrgu krüpteerib.
auth autendib pakette, mitte kandevõrku
Direktiiv auth valib HMAC-kokkuvõtte, mis autendib pakette, ja selle ajalooline vaikeväärtus on SHA1. Mitte-AEAD andmešifri korral arvutab OpenVPN kokkuvõtte šifreeritud teksti üle ja lisab selle, krüpteeri-seejärel-MAC korraldus, mis teeb polsterdamisega manipuleerimise ebapraktiliseks.
Müüt on siin see, et auth tõstmine SHA512-le karastab tunnelit. See ei tõsta krüpteerimise tugevust ja kui läbiräägitud andmešifer on AEAD-režiim nagu AES-256-GCM, ei rakendata kokkuvõtet andmepakettidele üldse. GCM-silt autendib neid juba ja auth väärtus jääb juhtkanali HMAC-i ja kõigi veel kasutusel olevate mitte-AEAD šifrite jaoks.
Direktiiv on seega oluline, aga oluline kitsamas kohas, kui selle asukoht failis vihjab. Kontrollimine, milline šifer tegelikult läbi räägiti, ütleb teile, kas see üldse kehtib.
Lugege profiili veeru, mitte järgu järgi
Kolm küsimust eristavad kihte puhtalt ja igaühele vastab läbiräägitud sessiooni erinev osa. Milline šifer kaitseb kandevõrku? Milline silt või kokkuvõte garanteerib iga paketi ja kas kasutatav šifer nõuab üldse ühte? Kelle sertifikaat sulges käepigistuse ja kas juhtkanal on lisaks kaitstud tls-auth või tls-crypt abil?
Miski EC või ED tähises ei otsusta ühtki neist kolmest ja komplekti nimi üksi ei otsusta samuti ühtki neist. Läbiräägitud tulemus on ainus tõend, seega lugege seda, selle asemel et tuletada tugevust sõnavarast:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logEsimene käsk ütleb teile, millist allkirjaskeemi teie sertifikaat tegelikult kasutab, ja see on ainus usaldusväärne viis teada, kas töötate ECDSA või Ed25519-ga. Teine näitab juhtkanali rida, mille klient sessiooni jaoks logis, sealhulgas TLS-i versiooni ja komplekti, millel peatuti. Kui profiili muudatust ei saa põhjendada ühega neist kahest väljundist, on see tõenäoliselt muudatus nimes, mitte omaduses.