OpenVPN EC ընդդեմ ED՝ ինչու այս անունները ուժի սանդուղք չեն
EC, ED, ECDHE և auth պատասխանում են տարբեր հարցերի։ Նախքան որևէ բան համեմատելը կամ խմբագրելը, դասավորեք OpenVPN պրոֆիլը ըստ յուրաքանչյուր անվան կատարած աշխատանքի։
Տեղադրեք ec, ed, ecdh, ecdsa, auth և TLS ծածկագրերի ցանկը կողք-կողքի մեկ պրոֆիլում, և ֆայլը սկսում է նմանվել վեց դիրքով ուժի կարգավորիչի։ Բայց այդպես չէ։ Յուրաքանչյուր անուն պատասխանում է տարբեր հարցի, և երկու պրոֆիլներ, որոնք տարբերվում են դրանցից մեկով, պարտադիր չէ, որ մեկը մյուսից ուժեղ կամ թույլ լինեն։ Անունները ըստ նրանց կատարած աշխատանքի դասավորելը տևում է մոտ հինգ րոպե և կանխում է այն վատ փոփոխությունների մեծ մասը, որ մարդիկ անում են աշխատող կազմաձևում։
Ստորև դասավորությունը սկսվում է հենց շփոթությունից, ապա շարժվում է դեպի դուրս՝ պրոֆիլի այն մասերը, որոնք իրականում որոշում են՝ ինչն է պաշտպանում ձեր տրաֆիկը։ Յուրաքանչյուր բաժին հերթով վերցնում է մեկ սխալ ընթերցում և ցույց է տալիս, թե ինչին է անունն իրականում կապված։
Երկու տառ, երկու տարբեր հարց
Ամենաշատ վեճ առաջացնող զույգը EC-ն և ED-ն են, և վեճը սովորաբար ենթադրում է, որ դրանք մեկ հարցի մրցակից պատասխաններ են։ Դրանք նույնիսկ նույն առանցքի վրա չեն։ EC-ն նկարագրում է մաթեմատիկայի ընտանիք՝ էլիպտիկ կորերի գաղտնագրություն, որտեղ անվտանգությունը գալիս է կորի վրա դիսկրետ լոգարիթմի դժվարությունից, այլ ոչ թե մեծ վերջավոր դաշտում։
ED-ն նկարագրում է կորի ձև այդ ընտանիքի ներսում։ Twisted Edwards կորերը ներկայացում են, որն ընտրվել է արագության և մի քանի իրականացման սխալների դիմադրության համար, և Ed25519-ը այն անունն է, որը մարդիկ սովորաբար նկատի ունեն։ Կորը էլիպտիկ կորերի գաղտնագրության մրցակից չէ. այն էլիպտիկ կոր գրելու եղանակներից մեկն է։ ED-ն «ավելի նոր, ավելի ուժեղ EC» կարդալը առաջին սխալ թեքումն է, և դրանից հետո ամեն ինչ սովորաբար սխալ է նույն ուղղությամբ։
Ստորագրելը և փոխանակելը առանձին աշխատանքներ են
Երբ ընտանիքի հարցը լուծված է, մնացած անունները բաժանվում են երկու սյունակի, որոնք երբեք չեն փոխարինում մեկը մյուսին։ Մեկ սյունակը ստորագրում է, մյուսը համաձայնության է գալիս ընդհանուր գաղտնիքի շուրջ։
| 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 |
Ե՛վ EdDSA-ն, և՛ ECDSA-ն ստորագրում են, բայց դրանք տարբեր սխեմաներ են՝ տարբեր բանալիների ձևաչափերով, ուստի մեկի համար թողարկված վկայականը չի կարող օգտագործվել որպես մյուսը։ EdDSA-ն սահմանված է կորերի փոքր բազմության համար. P-256-ը դրանցից չէ, դրա համար P-256 վկայականը ստուգվում է ECDSA-ով և երբեք Ed25519-ով։
Փոխանակման սյունակը EdDH անունով համարժեք չունի։ Curve25519 բանալու վրա էֆեմեր համաձայնությունը X25519-ն է, և դա ECDH է որոշակի կորով, ճիշտ այնպես, ինչպես P-256-ի դեպքում։ Ed25519-ը խստորեն նշանակում է ստորագրության սխեման, թեև անունը ազատորեն օգտագործվում է փոխանակման համար, քանի որ երկու կորերը կապված են. ստորագրելու համար օգտագործվող Edwards ձևը և X25519-ի համար օգտագործվող Montgomery ձևը նկարագրում են նույն հիմնական խումբը։
Ինչու EC պրոֆիլը dh ֆայլ չունի
dh ֆայլը պարունակում է վերջավոր դաշտի Diffie-Hellman-ի համար նախապես ստեղծված պարամետրեր, և այդ պարամետրերը գոյություն ունեն, որովհետև մեծ պարզ թիվն ու գեներատորը պետք է ինչ-որ տեղից գան։ Էլիպտիկ կորի փոխանակությունը դրանց կարիքը չունի. անվանված կորը հենց պարամետրերի հավաքածուն է, և երկու կողմերն արդեն գիտեն այն։ Սա է ամբողջ պատճառը, թե ինչու EC պրոֆիլը կարող է բաց թողնել հրահանգը։
Երկու իրավիճակ դեռ ստեղծում են dh տող այն պրոֆիլում, որն այլապես ժամանակակից է թվում։ Առաջինը երկրորդ լսողն է կամ ավելի հին գործընկերը, որն իսկապես բանակցում է վերջավոր դաշտի խմբերի շուրջ։ Երկրորդը RSA դարաշրջանի ձևանմուշից պատճենված և երբեք չհեռացված մնացորդային տեքստն է։ Պրոֆիլը, որը փոխանակման համար անվանում է կոր և դեռ բեռնում է 2048-բիթանոց dh ֆայլ, դրանով ավելի անվտանգ չէ. այն կրում է չօգտագործված առարկա։
TLS 1.3-ը հանեց բանալու փոխանակումը անունից
Համեմատեք TLS_AES_256_GCM_SHA384-ը TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384-ի հետ, և կարճ անունը նվազում է թվում։ Դա անվանափոխություն է, և պատճառը կառուցվածքային է. TLS 1.3-ը հեռացրեց ստատիկ RSA-ն և վերջավոր դաշտի Diffie-Hellman բանալու փոխանակությունը, ուստի էֆեմեր էլիպտիկ կորի փոխանակությունը միակ մնացած ոչ PSK տարբերակն է։ Այն ամեն հավաքածուում անվանելը կկրկներ նույն փաստը մեկ տասնյակ անգամ։
Վկայականի տեսակը անհետացավ անունից հարակից պատճառով։ 1.3-ում վկայականը հաստատում է ձեռքսեղմման ստորագրությունը, ոչ թե բանալու համաձայնությունը, ուստի այն այլևս չի ընտրում հավաքածուն։ Դա է նաև պատճառը, որ կազմաձևում 1.3-ի համար առանձին ծածկագրերի ցանկ կա. հավաքածուները վերանվանվեցին և վերակազմակերպվեցին, ոչ թե թուլացան։
Մի հետևանք արժե ուղղակի ասել։ ECDHE-ն բանալու փոխանակման ալգորիթմ է և երբեք ծածկագիր։ «Էլիպտիկ» նկարագրված հավաքածուն ինչ-որ բան ասում է այն մասին, թե ինչպես երկու կողմերը հասան ընդհանուր բանալու, և ոչինչ այն մասին, թե ինչն է հետո գաղտնագրում օգտակար բեռը։
auth-ը հաստատում է փաթեթները, ոչ բեռը
auth հրահանգը ընտրում է այն HMAC մարսողությունը, որն հաստատում է փաթեթները, և դրա պատմական լռելյայնը SHA1-ն է։ Ոչ AEAD տվյալների ծածկագրի դեպքում OpenVPN-ը հաշվարկում է մարսողությունը գաղտնագրված տեքստի վրա և կցում այն, սա «գաղտնագրիր, ապա MAC» դասավորությունն է, որն անիրագործելի է դարձնում լցոնման հետ մանիպուլյացիան։
Այստեղ առասպելն այն է, որ auth-ը SHA512-ի բարձրացնելը կարծրացնում է թունելը։ Այն չի բարձրացնում գաղտնագրման ուժը, և եթե բանակցված տվյալների ծածկագիրը AEAD ռեժիմ է, ինչպիսին AES-256-GCM-ն է, մարսողությունն ընդհանրապես չի կիրառվում տվյալների փաթեթների վրա։ GCM պիտակն արդեն հաստատում է դրանք, և auth արժեքը մնում է հսկիչ ալիքի HMAC-ի և դեռ օգտագործվող ցանկացած ոչ AEAD ծածկագրի համար։
Այսպիսով հրահանգը կարևոր է, բայց կարևոր է ավելի նեղ տեղում, քան հուշում է ֆայլում նրա դիրքը։ Ստուգելը, թե որ ծածկագիրն է իրականում բանակցվել, ասում է ձեզ՝ արդյոք այն ընդհանրապես կիրառվում է։
Կարդացեք պրոֆիլը ըստ սյունակի, ոչ ըստ աստիճանի
Երեք հարց մաքուր բաժանում են շերտերը, և յուրաքանչյուրին պատասխանում է բանակցված նստաշրջանի տարբեր մաս։ Ո՞ր ծածկագիրն է պաշտպանում օգտակար բեռը։ Ո՞ր պիտակը կամ մարսողությունն է երաշխավորում յուրաքանչյուր փաթեթը, և արդյոք օգտագործվող ծածկագիրն ընդհանրապես դրա կարիքն ունի։ Ու՞մ վկայականն է փակել ձեռքսեղմումը, և արդյոք հսկիչ ալիքը լրացուցիչ պաշտպանված է tls-auth-ով կամ tls-crypt-ով։
EC կամ ED պիտակում ոչինչ չի լուծում այդ երեքից ոչ մեկը, և հավաքածուի անունը ինքնին նույնպես չի լուծում դրանցից ոչ մեկը։ Բանակցված արդյունքը միակ ապացույցն է, ուստի կարդացեք այն՝ ուժը բառապաշարից եզրակացնելու փոխարեն:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logԱռաջին հրամանը ձեզ ասում է, թե ձեր վկայականն իրականում որ ստորագրության սխեման է օգտագործում, և դա իմանալու միակ վստահելի ձևն է, թե դուք աշխատում եք ECDSA-ով, թե Ed25519-ով։ Երկրորդը ցույց է տալիս հսկիչ ալիքի այն տողը, որը հաճախորդը գրանցել է նստաշրջանի համար, ներառյալ TLS տարբերակը և այն հավաքածուն, որի վրա այն կանգ է առել։ Եթե պրոֆիլի փոփոխությունը չի կարող արդարացվել այդ երկու ելքերից մեկով, ապա դա հավանաբար անվան փոփոխություն է, ոչ թե հատկության։