OpenVPN EC pret ED: kāpēc šie nosaukumi nav stipruma kāpnes
EC, ED, ECDHE un auth atbild uz dažādiem jautājumiem. Pirms kaut ko salīdzināt vai rediģēt, sakārtojiet OpenVPN profilu pēc darba, ko veic katrs nosaukums.
Ievietojiet ec, ed, ecdh, ecdsa, auth un TLS šifru sarakstu vienu otram blakus vienā profilā, un fails sāk izskatīties kā sešu pozīciju stipruma regulators. Bet tas tā nav. Katrs nosaukums atbild uz citu jautājumu, un divi profili, kas atšķiras vienā no tiem, ne vienmēr ir stiprāki vai vājāki viens par otru. Nosaukumu sakārtošana pēc to veiktā darba aizņem apmēram piecas minūtes un novērš lielāko daļu slikto labojumu, ko cilvēki izdara strādājošā konfigurācijā.
Tālākā kārtošana sākas ar pašu apjukumu un pēc tam virzās uz āru, pie tām profila daļām, kas patiešām nosaka, kas aizsargā jūsu trafiku. Katra sadaļa pēc kārtas paņem vienu nepareizu lasījumu un parāda, kam nosaukums patiešām ir piesaistīts.
Divi burti, divi dažādi jautājumi
Pāris, kas izraisa visvairāk strīdu, ir EC un ED, un strīds parasti pieņem, ka tie ir konkurējošas atbildes uz vienu jautājumu. Tie pat nav uz vienas ass. EC apraksta matemātikas saimi: eliptisko līkņu kriptogrāfiju, kur drošība nāk no diskrētā logaritma grūtības uz līknes, nevis lielā galīgā laukā.
ED apraksta līknes formu šīs saimes ietvaros. Twisted Edwards līknes ir attēlojums, kas izvēlēts ātruma un izturības pret vairākām ieviešanas kļūdām dēļ, un Ed25519 ir nosaukums, ko cilvēki parasti domā. Līkne nav eliptisko līkņu kriptogrāfijas konkurents; tā ir viens no veidiem, kā uzrakstīt eliptisku līkni. ED lasīšana kā "jaunākais, stiprākais EC" ir pirmais nepareizais pagrieziens, un viss pēc tam parasti ir nepareizs tajā pašā virzienā.
Parakstīšana un apmaiņa ir atsevišķi darbi
Kad saimes jautājums ir atrisināts, atlikušie nosaukumi sadalās divās kolonnās, kas nekad neaizstāj viena otru. Viena kolonna paraksta, otra vienojas par kopīgu noslēpumu.
| 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 |
Gan EdDSA, gan ECDSA paraksta, taču tie ir dažādas shēmas ar dažādiem atslēgu formātiem, tāpēc vienam izsniegts sertifikāts nav izmantojams kā otrs. EdDSA ir definēta nelielai līkņu kopai; P-256 nav viena no tām, tāpēc P-256 sertifikāts tiek pārbaudīts ar ECDSA un nekad ar Ed25519.
Apmaiņas kolonnā nav ekvivalenta ar nosaukumu EdDH. Efemēra vienošanās uz Curve25519 atslēgas ir X25519, un tas ir ECDH ar konkrētu līkni, tieši tāpat kā ar P-256. Ed25519 strikti nozīmē paraksta shēmu, lai gan nosaukums tiek brīvi lietots arī apmaiņai, jo abas līknes ir saistītas: parakstīšanai izmantotā Edwards forma un X25519 izmantotā Montgomery forma apraksta vienu un to pašu pamatgrupu.
Kāpēc EC profilā nav dh faila
dh fails satur iepriekš ģenerētus parametrus galīgā lauka Diffie-Hellman, un šie parametri pastāv tāpēc, ka lielam pirmskaitlim un ģeneratoram kaut kur jārodas. Eliptiskās līknes apmaiņai tie nav vajadzīgi: nosauktā līkne ir parametru kopa, un abas puses to jau zina. Tas ir viss iemesls, kāpēc EC profils var izlaist direktīvu.
Divas situācijas joprojām rada dh rindu profilā, kas citādi izskatās moderns. Pirmā ir otrs klausītājs vai vecāks partneris, kas patiešām pārrunā galīgā lauka grupas. Otrā ir pāri palicis teksts, kas nokopēts no RSA laikmeta veidnes un nekad nav noņemts. Profils, kas nosauc līkni apmaiņai un joprojām ielādē 2048 bitu dh failu, nav drošāks tāpēc, ka to izdarījis; tas nēsā neizmantotu artefaktu.
TLS 1.3 izņēma atslēgu apmaiņu no nosaukuma
Salīdziniet TLS_AES_256_GCM_SHA384 ar TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 un īsākais nosaukums izskatās kā pazeminājums. Tā ir pārdēvēšana, un iemesls ir strukturāls: TLS 1.3 izņēma statisko RSA un galīgā lauka Diffie-Hellman atslēgu apmaiņu, tāpēc efemēra eliptiskās līknes apmaiņa ir vienīgā atlikusī bez PSK iespēja. Tās nosaukšana katrā komplektā atkārtotu vienu un to pašu faktu duci reižu.
Sertifikāta tips no nosaukuma pazuda saistīta iemesla dēļ. Versijā 1.3 sertifikāts autentificē rokasspiediena parakstu, nevis atslēgu vienošanos, tāpēc tas vairs neizvēlas komplektu. Tāpēc konfigurācijā ir atsevišķs šifru saraksts 1.3 versijai: komplekti tika pārdēvēti un pārkārtoti, nevis vājināti.
Vienu sekvu ir vērts pateikt tieši. ECDHE ir atslēgu apmaiņas algoritms un nekad nav šifrs. Komplekts, kas aprakstīts kā "eliptisks", pasaka kaut ko par to, kā abas puses nonāca pie kopīgas atslēgas, un neko par to, kas pēc tam šifrē lietderīgo slodzi.
auth autentificē paketes, nevis lietderīgo slodzi
Direktīva auth izvēlas HMAC kopsavilkumu, kas autentificē paketes, un tās vēsturiskā noklusējuma vērtība ir SHA1. Ar datu šifru, kas nav AEAD, OpenVPN aprēķina kopsavilkumu pār šifrēto tekstu un pievieno to, kas ir šifrēt-tad-MAC izkārtojums, kas padara manipulācijas ar polsterējumu nepraktiskas.
Mīts šeit ir tāds, ka auth paaugstināšana līdz SHA512 nocietina tuneli. Tas nepalielina šifrēšanas stiprumu, un, ja saskaņotais datu šifrs ir AEAD režīms, piemēram, AES-256-GCM, kopsavilkums datu paketēm netiek piemērots vispār. GCM tags jau tos autentificē, un auth vērtība paliek vadības kanāla HMAC un jebkuram joprojām izmantotam šifram bez AEAD.
Tātad direktīva ir svarīga, bet tā ir svarīga šaurākā vietā, nekā liecina tās novietojums failā. Pārbaude, kurš šifrs patiešām tika saskaņots, pasaka, vai tā vispār attiecas.
Lasiet profilu pa kolonnām, nevis pa rangu
Trīs jautājumi tīri atdala slāņus, un uz katru atbild cita saskaņotās sesijas daļa. Kurš šifrs aizsargā lietderīgo slodzi? Kurš tags vai kopsavilkums galvo par katru paketi, un vai izmantotajam šifram tas vispār ir vajadzīgs? Kura sertifikāts aizvēra rokasspiedienu, un vai vadības kanāls papildus ir aizsargāts ar tls-auth vai tls-crypt?
Nekas EC vai ED apzīmējumā neatrisina nevienu no šiem trim, un arī komplekta nosaukums pats par sevi neatrisina nevienu no tiem. Saskaņotais rezultāts ir vienīgais pierādījums, tāpēc lasiet to, nevis seciniet stiprumu no vārdu krājuma:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logPirmā komanda pasaka, kuru paraksta shēmu jūsu sertifikāts patiešām izmanto, un tas ir vienīgais uzticamais veids, kā zināt, vai strādājat ar ECDSA vai Ed25519. Otrā parāda vadības kanāla rindu, ko klients ierakstīja sesijai, tostarp TLS versiju un komplektu, pie kura tas apstājās. Ja profila labojumu nevar pamatot ar vienu no šiem diviem izvadiem, tas droši vien ir nosaukuma, nevis īpašības maiņa.