OpenVPN EC EDren aurka: zergatik izen hauek ez diren indar-eskala bat

Jarri ec, ed, ecdh, ecdsa, auth eta TLS zifratze-zerrenda bat elkarren ondoan profil berean, eta fitxategia sei posizioko indar-dial baten antza hartzen hasten da. Baina ez da. Izen bakoitzak galdera ezberdin bati erantzuten dio, eta horietako batean desberdintzen diren bi profil ez dira nahitaez elkarrena baino indartsuagoak edo ahulagoak. Izenak egiten duten lanaren arabera sailkatzeak bost minutu inguru hartzen ditu eta konfigurazio funtzional batean jendeak egiten dituen aldaketa txarren gehienak saihesten ditu.

Beheko sailkapena nahasmenduitik bertatik hasten da, eta gero kanporantz zabaltzen da zure trafikoa babesten duena benetan erabakitzen duten profilaren zatietara. Atal bakoitzak irakurketa oker bat hartzen du txandaka eta izena benetan zeri lotuta dagoen erakusten du.

Bi letra, bi galdera ezberdin

Eztabaida gehien sortzen duen bikotea EC eta ED da, eta eztabaidak normalean suposatzen du galdera bati emandako erantzun arerioak direla. Ez daude ardatz berean ere. EC matematika-familia bat deskribatzen du: kurba eliptikoko kriptografia, non segurtasuna kurba bateko logaritmo diskretuaren zailtasunetik datorren, eta ez eremu finitu handi batean.

ED familia horren barruko kurba-forma bat deskribatzen du. Twisted Edwards kurbak abiadura eta inplementazio-errore batzuen aurkako erresistentzia dela eta hautatutako irudikapen bat dira, eta Ed25519 jendeak normalean esan nahi duen izena da. Kurba ez da kurba eliptikoko kriptografiaren lehiakide; kurba eliptiko bat idazteko modu bat da. ED "EC berriagoa eta indartsuagoa" gisa irakurtzea lehenengo bira okerra da, eta haren ondorengo guztia norabide berean okerra izateko joera du.

Sinatzea eta trukatzea lan bereiziak dira

Familiaren galdera konponduta, gainerako izenak inoiz elkar ordezkatzen ez duten bi zutabetan banatzen dira. Zutabe batek sinatzen du, besteak sekretu partekatu bat adosten du.

EdDSA eta ECDSA biek sinatzen dute, baina gako-formatu ezberdineko eskema ezberdinak dira, beraz baterako jaulkitako ziurtagiria ezin da beste gisa erabili. EdDSA kurba-multzo txiki baterako dago definituta; P-256 ez da horietako bat, eta horregatik P-256 ziurtagiri bat ECDSA-rekin egiaztatzen da eta inoiz ez Ed25519-rekin.

Truke-zutabeak ez dauka EdDH izeneko baliokiderik. Curve25519 gako baten gaineko akordio efimeroa X25519 da, eta hori kurba jakin bateko ECDH da, P-256-rekin bezalaxe. Ed25519-k zorrotz sinadura-eskema esan nahi du, nahiz eta izena trukerako lasai erabiltzen den bi kurbak erlazionatuta daudelako: sinatzeko erabiltzen den Edwards formak eta X25519rako erabiltzen den Montgomery formak azpiko talde bera deskribatzen dute.

Zergatik ez duen EC profilek dh fitxategirik

dh fitxategi batek eremu finituko Diffie-Hellmanerako aurrez sortutako parametroak ditu, eta parametro horiek badaude zenbaki lehen handi bat eta sortzaile bat nondikbait etorri behar direlako. Kurba eliptikoko truke batek ez ditu behar: izendatutako kurba da parametro-multzoa, eta bi aldeek jada ezagutzen dute. Hori da EC profilek direktiba baztertu ahal izateko arrazoi osoa.

Bi egoerak oraindik dh lerro bat sortzen dute bestela modernoa dirudien profilean. Lehenengoa eremu finituko taldeak benetan negoziatzen dituen bigarren entzule edo kide zaharrago bat da. Bigarrena RSA aroko txantiloi batetik kopiatu eta inoiz kendu ez zen testu soberakina da. Trukerako kurba bat izendatzen duen eta oraindik 2048 biteko dh fitxategia kargatzen duen profil bat ez da seguruagoa hori egin izanagatik; erabili gabeko artefaktu bat darama.

TLS 1.3-k gako-trukea kendu zuen izenetik

Konparatu TLS_AES_256_GCM_SHA384 eta TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, eta izen laburragoak beherapen bat dirudi. Izen-aldaketa da, eta arrazoia egiturazkoa da: TLS 1.3-k RSA estatikoaren eta eremu finituko Diffie-Hellman gako-trukearen kendu zituen, beraz kurba eliptikoko truke efimeroa da geratzen den PSK gabeko aukera bakarra. Suite bakoitzean izendatzeak gertaera bera dozenaka aldiz errepikatuko luke.

Ziurtagiri-mota izenetik desagertu zen lotutako arrazoi batengatik. 1.3-n ziurtagiriak eskuko ukitzearen sinadura egiaztatzen du, ez gako-akordioa, beraz jada ez du suitea hautatzen. Horregatik dago 1.3rako zifratze-zerrenda bereizi bat konfigurazioan: suiteak berrizendatu eta berrantolatu egin ziren, ez ziren ahuldu.

Ondorio bat argi esatea merezi du. ECDHE gako-truke algoritmoa da eta inoiz ez zifratze. "Eliptiko" gisa deskribatutako suite batek bi kideek gako partekatu batera nola iritsi ziren esaten du, eta ezer ez geroago karga erabilgarria zer zifratzen duen.

auth-ek paketeak autentifikatzen ditu, ez kargak

auth direktibak paketeak autentifikatzen dituen HMAC laburpena hautatzen du, eta haren balio lehenetsi historikoa SHA1 da. AEAD ez den datu-zifratze batekin, OpenVPN-ek laburpena zifratutako testuaren gainean kalkulatzen du eta erantsi egiten dio, zifratu-eta-gero-MAC antolaketa bat, betegarriarekin manipulatzen egitea praktikoa ez bihurtzen duena.

Hemen mitoa zera da: auth SHA512-ra igotzeak tunela gogortzen duela. Ez du zifratzearen indarra igotzen, eta negoziatutako datu-zifratzea AES-256-GCM bezalako AEAD modu bat bada, laburpena ez zaie datu-paketeei batere aplikatzen. GCM etiketak jada autentifikatzen ditu, eta auth balioa kontrol-kanalaren HMAC-rako eta oraindik erabiltzen den AEAD ez den edozein zifratzetarako uzten da.

Beraz direktibak axola du, baina fitxategian duen posizioak iradokitzen duen baino leku estuagoan axola du. Benetan zein zifratze negoziatu zen egiaztatzeak esaten dizu batere aplikatzen den.

Irakurri profila zutabeka, ez mailaka

Hiru galderak garbi bereizten dituzte geruzak, eta bakoitzari negoziatutako saioaren zati ezberdin batek erantzuten dio. Zein zifratzek babesten du karga erabilgarria? Zein etiketak edo laburpenek erantzuten du pakete bakoitzaren alde, eta erabiltzen den zifratzeak behar al du bat? Noren ziurtagiriak itxi zuen eskuko ukitzea, eta kontrol-kanala gainera tls-auth edo tls-crypt-ekin babestuta dago?

EC edo ED etiketaren ezerk ez du hiru horietako bat ere erabakitzen, eta suite-izen batek bakarrik ere ez du horietako bat ere erabakitzen. Negoziatutako emaitza da froga bakarra, beraz irakurri hura, hiztegian oinarrituta indarra ondorioztatu beharrean:

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

Lehenengo komandoak esaten dizu zure ziurtagiriak benetan zein sinadura-eskema erabiltzen duen, eta hori da ECDSA edo Ed25519 exekutatzen ari zaren jakiteko modu fidagarri bakarra. Bigarrenak bezeroak saiorako erregistratu zuen kontrol-kanalaren lerroa erakusten du, TLS bertsioa eta finkatu zen suitea barne. Profil-aldaketa bat irteera horietako batekin justifikatu ezin bada, ziurrenik izen aldaketa bat da, eta ez propietate bat.