OpenVPN EC kundrejt ED: pse këta emra nuk janë një shkallë force

Vendosni ec, ed, ecdh, ecdsa, auth dhe një listë shifrash TLS krah për krah në një profil, dhe skedari fillon të duket si një çelës force me gjashtë pozicione. Por nuk është. Çdo emër i përgjigjet një pyetjeje tjetër, dhe dy profile që ndryshojnë në një prej tyre nuk janë domosdoshmërisht më të fortë ose më të dobët se njëri-tjetri. Renditja e emrave sipas punës që bëjnë zgjat rreth pesë minuta dhe parandalon shumicën e ndryshimeve të këqija që njerëzit bëjnë në një konfigurim që funksionon.

Renditja më poshtë fillon nga vetë konfuzioni dhe më pas lëviz nga jashtë, drejt pjesëve të një profili që vendosin vërtet se çfarë mbron trafikun tuaj. Secili seksion merr me radhë një lexsim të gabuar dhe tregon se me çfarë lidhet në të vërtetë emri.

Dy shkronja, dy pyetje të ndryshme

Çifti që shkakton më shumë debat është EC dhe ED, dhe debati zakonisht supozon se janë përgjigje rivale ndaj një pyetjeje të vetme. Nuk janë as në të njëjtin bosht. EC përshkruan një familje matematike: kriptografia e kurbës eliptike, ku siguria vjen nga vështirësia e një logaritmi diskret në një kurbë dhe jo në një fushë të fundme të madhe.

ED përshkruan një formë kurbe brenda asaj familjeje. Kurbat Twisted Edwards janë një paraqitje e zgjedhur për shpejtësi dhe për rezistencë ndaj disa gabimeve të zbatimit, dhe Ed25519 është emri që njerëzit zakonisht nënkuptojnë. Kurba nuk është konkurrente e kriptografisë së kurbës eliptike; është një mënyrë për të shkruar një kurbë eliptike. Leximi i ED si "EC më e re dhe më e fortë" është kthesa e parë e gabuar, dhe gjithçka pas saj priret të jetë e gabuar në të njëjtin drejtim.

Nënshkrimi dhe shkëmbimi janë punë të ndara

Pasi zgjidhet çështja e familjes, emrat e mbetur ndahen në dy kolona që nuk zëvendësojnë kurrë njëra-tjetrën. Njëra kolonë nënshkruan, tjetra bie dakord për një sekret të përbashkët.

EdDSA dhe ECDSA nënshkruajnë të dyja, por janë skema të ndryshme me formate të ndryshme kyçesh, prandaj një certifikatë e lëshuar për njërën nuk është e përdorshme si tjetra. EdDSA është përcaktuar për një grup të vogël kurbash; P-256 nuk është një prej tyre, prandaj një certifikatë P-256 verifikohet me ECDSA dhe kurrë me Ed25519.

Kolona e shkëmbimit nuk ka një ekuivalent të quajtur EdDH. Marrëveshja efemere mbi një kyç Curve25519 është X25519, dhe kjo është ECDH me një kurbë të caktuar, saktësisht si me P-256. Ed25519 nënkupton rreptësisht skemën e nënshkrimit, megjithëse emri përdoret lirshëm për shkëmbimin sepse dy kurbat janë të lidhura: forma Edwards e përdorur për nënshkrim dhe forma Montgomery e përdorur për X25519 përshkruajnë të njëjtin grup bazë.

Pse një profil EC nuk ka skedar dh

Një skedar dh përmban parametra të gjeneruar paraprakisht për Diffie-Hellman në fushë të fundme, dhe ata parametra ekzistojnë sepse një numër i thjeshtë i madh dhe një gjenerator duhet të vijnë nga diku. Një shkëmbim në kurbë eliptike nuk i nevojit ata: kurba e emërtuar është grupi i parametrave, dhe të dyja palët tashmë e njohin atë. Ky është i gjithë arsyeja pse një profil EC mund të heqë direktivën.

Dy situata ende prodhojnë një rresht dh në një profil që përndryshe duket modern. E para është një dëgjues i dytë ose një partner më i vjetër që vërtet negocion grupe të fushës së fundme. E dyta është tekst i mbetur i kopjuar nga një shabllon i epokës RSA dhe i hequr kurrë. Një profil që emërton një kurbë për shkëmbimin dhe ende ngarkon një skedar dh 2048-bitësh nuk është më i sigurt sepse e bëri këtë; ai mbart një artefakt të papërdorur.

TLS 1.3 hoqi shkëmbimin e kyçeve nga emri

Krahasoni TLS_AES_256_GCM_SHA384 me TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 dhe emri më i shkurtër duket si një ulje. Është një riemërtim, dhe arsyeja është strukturore: TLS 1.3 hoqi RSA statik dhe shkëmbimin e kyçeve Diffie-Hellman në fushë të fundme, prandaj një shkëmbim efemer në kurbë eliptike është opsioni i vetëm i mbetur jo-PSK. Emërtimi i tij në çdo suitë do të përsëriste të njëjtin fakt një duzinë herë.

Lloji i certifikatës u zhduk nga emri për një arsye të lidhur. Në 1.3 certifikata vërteton nënshkrimin e shtrëngimit të duarve, jo marrëveshjen e kyçeve, prandaj nuk e zgjedh më suitën. Për këtë arsye ekziston një listë e veçantë shifrash për 1.3 në konfigurim: suitat u riemërtuan dhe u riorganizuan, nuk u dobësuan.

Një pasojë meriton të thuhet troç. ECDHE është një algoritëm shkëmbimi kyçesh dhe kurrë një shifër. Një suitë e përshkruar si "eliptike" thotë diçka për mënyrën se si dy palët arritën në një kyç të përbashkët, dhe asgjë për atë që më pas kripton ngarkesën.

auth vërteton paketat, jo ngarkesat

Direktiva auth zgjedh përmbledhjen HMAC që vërteton paketat, dhe vlera e saj e parazgjedhur historike është SHA1. Me një shifër të dhënash që nuk është AEAD, OpenVPN llogarit përmbledhjen mbi tekstin e kriptuar dhe e shton atë, një rregullim kripto-pastaj-MAC që e bën të papraktikë manipulimin e mbushjes.

Miti këtu është se ngritja e auth në SHA512 e forcon tunelin. Nuk e rrit forcën e kriptimit, dhe nëse shifra e dhënave e negociuar është një modalitet AEAD si AES-256-GCM, përmbledhja nuk zbatohet fare mbi paketat e dhënave. Etiketa GCM tashmë i vërteton ato, dhe vlera auth mbetet për HMAC-në e kanalit të kontrollit dhe për çdo shifër jo-AEAD që përdoret ende.

Pra direktiva ka rëndësi, por ka rëndësi në një vend më të ngushtë sesa sugjeron pozicioni i saj në skedar. Kontrolli se cila shifër u negociua në të vërtetë ju tregon nëse zbatohet fare.

Lexoni profilin sipas kolonës, jo sipas renditjes

Tri pyetje i ndajnë shtresat pastër, dhe secilës i përgjigjet një pjesë tjetër e sesionit të negociuar. Cila shifër mbron ngarkesën? Cila etiketë ose përmbledhje garanton për çdo paketë, dhe a e kërkon fare shifra që përdoret? Certifikata e kujt e mbylli shtrëngimin e duarve, dhe a mbrohet kanali i kontrollit përveç kësaj nga tls-auth ose tls-crypt?

Asgjë në etiketën EC ose ED nuk zgjidh asnjërën prej atyre tre, dhe as emri i suitës i vetëm nuk zgjidh asnjërën prej tyre. Rezultati i negociuar është prova e vetme, prandaj lexoni atë në vend që të nxirrni forcën nga fjalori:

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

Komanda e parë ju tregon se cilën skemë nënshkrimi përdor vërtet certifikata juaj, dhe ky është mënyra e vetme e besueshme për të ditur nëse jeni duke ekzekutuar ECDSA ose Ed25519. E dyta tregon rreshtin e kanalit të kontrollit që klienti regjistroi për sesionin, duke përfshirë versionin TLS dhe suitën në të cilën u ndal. Nëse një ndryshim i profilit nuk mund të justifikohet nga një prej këtyre dy daljeve, ka të ngjarë të jetë një ndryshim emri dhe jo vetie.