OpenVPN EC kontraŭ ED: kial la nomoj ne estas ŝtuparo de forto
EC, ED, ECDHE kaj auth respondas al malsamaj demandoj. Ordigi OpenVPN-profilon laŭ la tasko, kiun plenumas ĉiu nomo, antaŭ ol vi komparos aŭ redaktos ion ajn.
Metu ec, ed, ecdh, ecdsa, auth kaj liston da TLS-ĉifroj unu apud la alia en unu profilon kaj la dosiero komencas aspekti kiel forta turnobutono kun ses pozicioj. Sed ĝi ne estas. Ĉiu nomo respondas al malsama demando, kaj du profiloj, kiuj diferencas en unu el ili, ne nepre estas pli fortaj aŭ pli malfortaj ol la alia. Ordigi la nomojn laŭ la tasko, kiun ili plenumas, daŭras proksimume kvin minutojn kaj malhelpas la plej multajn el la malbonaj ŝanĝoj, kiujn homoj faras en funkcianta agordo.
La suba ordigo komenciĝas de la konfuzo mem, poste iras eksteren al tiuj partoj de profilo, kiuj efektive decidas, kio protektas vian trafikon. Ĉiu sekcio prenas laŭvice unu mislegon kaj montras, al kio la nomo vere ligiĝas.
Du literoj, du malsamaj demandoj
La paro, kiu kaŭzas la plej multajn debatojn, estas EC kaj ED, kaj la debato kutime supozas, ke ili estas rivalaj respondoj al unu demando. Ili eĉ ne estas sur la sama akso. EC priskribas familion de matematiko: kriptografio per elipsaj kurboj, kie la sekureco venas de la malfacileco de diskreta logaritmo sur kurbo, ne en granda finia kampo.
ED priskribas kurbformon ene de tiu familio. La kurboj Twisted Edwards estas reprezento elektita por rapideco kaj por rezisto al pluraj efektivigaj eraroj, kaj Ed25519 estas la nomo, kiun homoj kutime celas. La kurbo ne estas konkurencanto de kriptografio per elipsaj kurboj; ĝi estas unu maniero skribi elipsan kurbon. Legi ED kiel "la pli nova, pli forta EC" estas la unua malĝusta turno, kaj ĉio post ĝi emas esti malĝusta en la sama direkto.
Subskribi kaj interŝanĝi estas apartaj taskoj
Post kiam la demando pri la familio estas solvita, la ceteraj nomoj dividiĝas en du kolumnojn, kiuj neniam anstataŭas unu la alian. Unu kolumno subskribas, la alia interkonsentas pri komuna sekreto.
| 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 |
Kaj EdDSA kaj ECDSA subskribas, sed ili estas malsamaj skemoj kun malsamaj ŝlosilformatoj, do atesto eldonita por unu ne estas uzebla kiel la alia. EdDSA estas difinita por malgranda aro da kurboj; P-256 ne estas unu el ili, kio klarigas, kial atesto P-256 validiĝas per ECDSA kaj neniam per Ed25519.
La kolumno de interŝanĝo havas neniun ekvivalenton nomatan EdDH. Efemera interkonsento pri ŝlosilo Curve25519 estas X25519, kaj tio estas ECDH kun difinita kurbo, same kiel ĉe P-256. Ed25519 strikte signifas la subskriban skemon, kvankam la nomo estas uzata loze por la interŝanĝo, ĉar la du kurboj rilatas: la formo Edwards uzata por subskribi kaj la formo Montgomery uzata por X25519 priskribas la saman suban grupon.
Kial EC-profilo ne havas dosieron dh
Dosiero dh enhavas antaŭe generitajn parametrojn por Diffie-Hellman en finia kampo, kaj tiuj parametroj ekzistas ĉar granda primo kaj generatoro devas veni de ie. Elips-kurba interŝanĝo ne bezonas ilin: la nomita kurbo estas la parametraro, kaj ambaŭ flankoj jam konas ĝin. Tio estas la tuta kialo, kial EC-profilo povas preterlasi la direktivon.
Du situacioj ankoraŭ produktas linion dh en profilo, kiu alie aspektas moderna. La unua estas dua aŭskultanto aŭ pli malnova kunulo, kiu vere intertraktas grupojn de finia kampo. La dua estas restinta teksto kopiita el ŝablono de la RSA-epoko kaj neniam forigita. Profilo, kiu nomas kurbon por la interŝanĝo kaj ankoraŭ ŝargas dh-dosieron de 2048 bitoj, ne estas pli sekura pro tio; ĝi portas neuzatan artefakton.
TLS 1.3 forigis la ŝlosilan interŝanĝon el la nomo
Komparu TLS_AES_256_GCM_SHA384 kun TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 kaj la pli mallonga nomo aspektas kiel malaltigo. Ĝi estas renomigo, kaj la kialo estas struktura: TLS 1.3 forigis statikan RSA kaj la ŝlosilan interŝanĝon Diffie-Hellman en finia kampo, do efemera elips-kurba interŝanĝo estas la sola restanta ne-PSK-opcio. Nomi ĝin en ĉiu suito ripetus la saman fakton dekdu fojojn.
La atesta tipo malaperis el la nomo pro rilata kialo. En 1.3 la atesto aŭtentikigas la subskribon de la manpremo, ne la ŝlosilan interkonsenton, do ĝi ne plu elektas la suiton. Tio ankaŭ klarigas, kial ekzistas aparta ĉifrolisto por 1.3 en la agordo: la suitoj estis renomitaj kaj reorganizitaj, ne malfortigitaj.
Unu sekvo indas esti dirita malkaŝe. ECDHE estas ŝlosilinterŝanĝa algoritmo kaj neniam ĉifro. Suito priskribita kiel "elipsa" diras ion pri tio, kiel la du kunuloj atingis komunan ŝlosilon, kaj nenion pri tio, kio poste ĉifras la utilan ŝarĝon.
auth aŭtentikigas pakaĵojn, ne utilajn ŝarĝojn
La direktivo auth elektas la HMAC-kompendion, kiu aŭtentikigas pakaĵojn, kaj ĝia historia defaŭlto estas SHA1. Ĉe ne-AEAD-datumĉifro, OpenVPN komputas la kompendion super la ĉifroteksto kaj aldonas ĝin, aranĝo ĉifru-poste-MAC, kiu igas manipuli la plenigaĵon nepraktika.
La mito ĉi tie estas, ke altigi auth al SHA512 firmigas la tunelon. Ĝi ne altigas la forton de la ĉifrado, kaj se la intertraktita datumĉifro estas AEAD-reĝimo kiel AES-256-GCM, la kompendio tute ne aplikiĝas al datumaj pakaĵoj. La GCM-etikedo jam aŭtentikigas ilin, kaj la valoro auth restas por la HMAC de la rega kanalo kaj por ĉiu ne-AEAD-ĉifro ankoraŭ uzata.
Do la direktivo gravas, sed ĝi gravas en pli mallarĝa loko ol ĝia pozicio en la dosiero sugestas. Kontroli, kiu ĉifro estis efektive intertraktita, diras al vi, ĉu ĝi entute validas.
Legu la profilon laŭ kolumno, ne laŭ rango
Tri demandoj klare apartigas la tavolojn, kaj ĉiun respondas malsama parto de la intertraktita sesio. Kiu ĉifro protektas la utilan ŝarĝon? Kiu etikedo aŭ kompendio garantias por ĉiu pakaĵo, kaj ĉu la uzata ĉifro entute bezonas unu? Kies atesto fermis la manpremon, kaj ĉu la rega kanalo estas krome gardata de tls-auth aŭ tls-crypt?
Nenio en la etikedo EC aŭ ED solvas iun el tiuj tri, kaj suita nomo sola ankaŭ solvas neniun el ili. La intertraktita rezulto estas la sola pruvo, do legu ĝin anstataŭ dedukti forton el vortprovizo:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logLa unua komando diras al vi, kiun subskriban skemon via atesto efektive uzas, kaj tio estas la sola fidinda maniero scii, ĉu vi uzas ECDSA aŭ Ed25519. La dua montras la linion de la rega kanalo, kiun la kliento registris por la sesio, inkluzive de la TLS-versio kaj la suito, ĉe kiu ĝi haltis. Se ŝanĝo de profilo ne povas esti pravigita per unu el tiuj du eligoj, ĝi verŝajne estas ŝanĝo de nomo kaj ne de eco.