OpenVPN EC tsjin ED: wêrom’t de nammen gjin krêftljedder binne
EC, ED, ECDHE en auth beantwurdzje ferskillende fragen. Sortearje in OpenVPN-profyl nei it wurk dat elke namme docht foardat jo wat fergelykje of bewurkje.
Set ec, ed, ecdh, ecdsa, auth en in TLS-siferyl list neist elkoar yn ien profyl, en it bestân begjint der as in krêftdraaiknop mei seis stannen út te sjen. Mar dat is it net. Eltse namme beantwurdet in oare fraach, en twa profilen dy’t yn ien fan har ferskille, binne net needsaaklikerwize sterker of swakker as elkoar. It sortearjen fan de nammen nei it wurk dat se dogge duorret sa’n fiif minuten en foarkomt it measte fan de minne bewurkingen dy’t minsken oan in wurkjende konfiguraasje dogge.
It sortearjen hjirûnder begjint by de betizing sels en giet dan nei bûten ta, nei de dielen fan in profyl dy’t echt bepale wat jo ferkear beskermet. Eltse seksje nimt op syn bart ien ferkearde lêzing en lit sjen wêr’t de namme echt oan fêst sit.
Twa letters, twa ferskillende fragen
It pear dat de measte diskusje feroarsaket is EC en ED, en de diskusje giet der meast fan út dat se rivaalantwurden op ien fraach binne. Se sitte net iens op deselde as. EC beskriuwt in famylje fan wiskunde: kryptografy op elliptyske krommen, wêr’t de feiligens komt fan de swierrichheid fan in diskreet logaritme op in kromme en net yn in grut einich fjild.
ED beskriuwt in krommefoarm binnen dy famylje. Twisted Edwards-krommen binne in foarstelling dy’t keazen is foar faasje en foar wjerstân tsjin ferskate ymplemintaasjeflaters, en Ed25519 is de namme dy’t minsken meast bedoele. De kromme is gjin konkurrint fan kryptografy op elliptyske krommen; it is ien manier om in elliptyske kromme te skriuwen. ED lêze as "de nijere, sterkere EC" is de earste ferkearde bocht, en alles dêrnei is meast ferkeard yn deselde rjochting.
Undertekenje en útwikselje binne aparte taken
As de famyljefraach besljochte is, ferdiele de oare nammen har yn twa kolommen dy’t nea foar elkoar yn it plak komme. Ien kolom ûndertekenet, de oare komt oerien op in dield geheim.
| 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 |
Sawol EdDSA as ECDSA ûndertekenje, mar it binne ferskillende skema’s mei ferskillende kaaiformaten, sadat in sertifikaat dat foar de iene útjûn is net as de oare brûkber is. EdDSA is definiearre foar in lytse set krommen; P-256 is dêr net ien fan, en dêrom wurdt in P-256-sertifikaat mei ECDSA ferifiearre en nea mei Ed25519.
De útwikselkolom hat gjin ekwivalent dat EdDH hjit. Efemêre oerienkomst op in Curve25519-kaai is X25519, en dat is ECDH mei in bepaalde kromme, krekt as by P-256. Ed25519 betsjut strikt it ûndertekeningsskema, al wurdt de namme loskes foar de útwiksel brûkt om’t de twa krommen besibbe binne: de Edwards-foarm foar it ûndertekenjen en de Montgomery-foarm foar X25519 beskriuwe deselde ûnderlizzende groep.
Wêrom’t in EC-profyl gjin dh-bestân hat
In dh-bestân befettet foarôf makke parameters foar Diffie-Hellman yn in einich fjild, en dy parameters besteane om’t in grut priemgetal en in generator earne wei komme moatte. In útwiksel op in elliptyske kromme hat se net nedich: de neamde kromme is de parameterset, en beide kanten kenne dy al. Dat is de hiele reden wêrom’t in EC-profyl de rjochtline weilitte kin.
Twa situaasjes meitsje noch hieltyd in dh-rige yn in profyl dat der oars modern útsjocht. De earste is in twadde harker of in âlder partner dy’t echt oer groepen yn in einich fjild ûnderhannelt. De twadde is oerbliuwende tekst dy’t út in sjabloan út it RSA-tiidrek kopiearre en nea fuortsmiten is. In profyl dat in kromme foar de útwiksel neamt en noch hieltyd in dh-bestân fan 2048 bit lade, is net feiliger om’t it dat dien hat; it draacht in net brûkt artefakt.
TLS 1.3 helle de kaai-útwiksel út de namme
Fergelykje TLS_AES_256_GCM_SHA384 mei TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 en de koartere namme sjocht der as in delgong út. It is in weroanmeitsjen, en de reden is struktureel: TLS 1.3 helle statyske RSA en Diffie-Hellman-kaai-útwiksel yn in einich fjild fuort, sadat in efemêre útwiksel op in elliptyske kromme de iennichste oerbleaune net-PSK-opsje is. It yn elke suite neame soe deselde feiten in dosyn kear werhelje.
It sertifikaattype ferdwûn om in besibbe reden út de namme. Yn 1.3 autentisearret it sertifikaat de ûndertekening fan de hânskodding, net de kaai-oerienkomst, sadat it net mear de suite kiest. Dêrom is der ek in aparte siferyllist foar 1.3 yn ‘e konfiguraasje: de suites binne weroanmakke en op ‘e nij oardere, net ferswakke.
Ien gefolch is it wurdich om gewoan te sizzen. ECDHE is in algoritme foar kaai-útwiksel en nea in sifer. In suite dy’t as "elliptysk" beskreaun wurdt, seit wat oer hoe’t de beide partners by in dielde kaai kamen, en neat oer wat dêrnei de lading fersifere.
auth autentisearret pakketten, net ladingen
De rjochtline auth kiest de HMAC-fertizing dy’t pakketten autentisearret, en de histoaryske standertwearde is SHA1. By in net-AEAD-datasifer berekkent OpenVPN de fertizing oer de sifertekst en foeget dy ta, in opbou fan fersiferje-dan-MAC dy’t it manipulearjen fan ‘e opfolging ûnpraktysk makket.
De myte hjir is dat it ferheegjen fan auth nei SHA512 de tunnel hurder makket. It ferheget de krêft fan ‘e fersifering net, en as de ûnderhannele datasifer in AEAD-modus is lykas AES-256-GCM, dan wurdt de fertizing hielendal net op datapakketten tapast. De GCM-tag autentisearret se al, en de auth-wearde bliuwt foar de HMAC fan it kontrôlekanaal en foar elk net-AEAD-sifer dat noch brûkt wurdt.
Dus de rjochtline is fan belang, mar fan belang op in smeller plak as har posysje yn it bestân suggerearret. Sjen hokker sifer echt ûnderhannele is, fertelt jo oft it wol fan tapassing is.
Lês it profyl per kolom, net per rang
Trije fragen skiede de lagen skjin, en op elk wurdt antwurde troch in oar part fan ‘e ûnderhannele sesje. Hokker sifer beskermet de lading? Hokker tag of fertizing stiet foar elk pakket yn, en hat it brûkte sifer der wol ien nedich? Hwa syn sertifikaat sleat de hânskodding, en is it kontrôlekanaal derneist beskerme troch tls-auth of tls-crypt?
Neat yn it EC- of ED-label beslist ien fan dy trije, en in suitenamme op himsels beslist ek net ien fan har. It ûnderhannele resultaat is it iennichste bewiis, dus lês dat ynstee fan krêft út ‘e wurdlist ôf te lieden:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logIt earste kommando fertelt jo hokker ûndertekeningsskema jo sertifikaat echt brûkt, en dat is de iennichste betroubere manier om te witten oft jo ECDSA of Ed25519 draaie. It twadde lit de rigel fan it kontrôlekanaal sjen dy’t de klant foar de sesje oan ‘e log taheakke, ynklusyf de TLS-ferzje en de suite dêr’t it op útkaam. As in profylbewurking net troch ien fan dy twa útgongen rjochtfeardige wurde kin, is it wierskynlik in feroaring oan in namme en net oan in eigenskip.