Ինչի՞ց է իրականում պաշտպանում VPN-ի անձնական բանալու գաղտնաբառը

VPN-ի հաճախորդի մեկնարկին հայտնվող հարցումը հեշտ է սխալ կարդալ։ Դա VPN-ի հաշվի գաղտնաբառը չէ, թունելի գաղտնաբառը չէ, և այն մուտքագրելը չի ապացուցում, որ կապը անվտանգ է։ Այն բացում է անձնական բանալու մեկ պահված ներկայացում, որպեսզի հաճախորդը կարողանա կարդալ բանալու նյութը և օգտագործել այն նույնականացման համար։ Այն ամենը, ինչ տեղի է ունենում դրանից հետո, այլ հարց է։

Գործնականում պատասխանը սխալվում է եզրերում. մարդիկ ենթադրում են, որ գաղտնաբառը պաշտպանում է աշխատող թունելը, կամ որ այն փոխելը չեղարկում է արդեն արտահոսած բանալու պատճենը։ Երկու ենթադրություններն էլ ձախողվում են, և ձախողվում են այնպես, որ հավատարմագրությունը մնում է բաց, մինչ օպերատորը կարծում է, թե հարցը լուծված է։

Մեկ երկխոսություն, մի քանի տարբեր գաղտնիքներ

Անձնական բանալու գաղտնաբառը վերծանում է ֆայլ։ Հաշվի գաղտնաբառը ձեզ նույնականացնում է ծառայության մոտ։ PKCS#12 ներմուծման գաղտնաբառը վերծանում է փաթեթ, որը պարունակում է բանալի և դրա վկայագիրը, և այն կարող է նույն տողը չլինել, ինչ բանալու սեփական գաղտնաբառը։ Այս հարցումները կարող են գրեթե նույնը թվալ, և թե որ գաղտնիքը որտեղ է գնում գուշակելը հենց այն է, ինչի պատճառով բանալիները սոսնձվում են սխալ դաշտում։

Թունելի սեփական գաղտնագրումը չորրորդ բանն է։ Տվյալների ալիքը օգտագործում է ձեռքսեղմման ընթացքում համաձայնեցված սեսիայի բանալիներ. անձնական բանալու գաղտնաբառը որևէ դեր չունի առանձին փաթեթների պաշտպանության մեջ։ Եթե ինչ-որ մեկը կարող է կարդալ բանալու ֆայլը, նա կարող է փորձել գուշակել գաղտնաբառը առանց ցանցի, բայց եթե կարող է կարդալ փաթեթները, գաղտնաբառը էական չէ։

Ինչ է ծածկում սկավառակի գաղտնագրումը

Գաղտնագրված PEM բանալին երկու ձև ունի, և վերնագիրը ասում է, թե որն ունեք։ Ժամանակակից PKCS#8 ձևը սկսվում է -----BEGIN ENCRYPTED PRIVATE KEY------ով. հին PEM ձևը, որը դեռ սովորական է հին OpenVPN կարգավորումներում, սկսվում է -----BEGIN RSA PRIVATE KEY------ով և ունի Proc-Type: 4,ENCRYPTED և DEK-Info տողը անմիջապես դրա տակ։ Ֆայլը պահում է անձնական բանալին գաղտնագրված ձեր գաղտնաբառից ածանցված բանալիով, սովորաբար գաղտնաբառի վրա հիմնված KDF-ի միջոցով՝ նշված կրկնությունների քանակով կամ աշխատանքի գործակիցով։ OpenSSL pkey փաստաթղթերը ընդգրկում են ձևաչափերը և գաղտնաբառի այն տարբերակները, որոնք կիրառվում են կարդալիս։

Դրանից բխում են երկու հետևանք։ Թույլ գաղտնաբառը կարող է հարձակման ենթարկվել առանց ցանցի այն արագությամբ, ինչ թույլ է տալիս KDF-ը, ուստի ֆայլի թույլտվությունները և պահուստային պատճենների հասանելիությունը դեռևս կարևոր են, նույնիսկ երբ ֆայլը գաղտնագրված է։ Եվ հարձակվողը, որը ստանում է միայն ֆայլը առանց գաղտնաբառի, պետք է գուշակի. ով ստանում է և՛ ֆայլը, և՛ գաղտնաբառը, ունի բանալին, ճիշտ այնպես, կարծես այն երբեք գաղտնագրված չի եղել։

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 ցույց է տալիս վերնագիրը և հին ֆայլում՝ գաղտնագրումն ապացուցող Proc-Type և DEK-Info տողերը. մեկ տողն ինքնին ոչ մի ուղղությամբ ապացույց չէ։ pkey տողը հարցնում է գաղտնաբառը և տպում է միայն հանրային կեսը, ինչը ապացուցում է, որ ֆայլը և գաղտնաբառը աշխատում են առանց անձնական բանալին բացահայտելու։ Այդ ստուգման համար մի օգտագործեք -text-ը. այն տպում է անձնական բաղադրիչները՝ privateExponent, prime1, prime2 և մնացածը, և այդ ելքը երբեք չպետք է որևէ տեղ տեղադրվի՝ ոչ տոմսում, ոչ զրույցում, ոչ մատյանում։ PKCS#12 հրամանը նաև ասում է՝ փաթեթն ունի առանձին MAC թե գաղտնագրման գաղտնաբառ, ինչը արժե իմանալ գործընկերոջը տալուց առաջ։

Ինչն է դադարում պաշտպանել բանալին բեռնվելուց հետո

Բացելը միակողմանի իրադարձություն է այդ գործընթացի համար։ Հաճախորդը KDF-ից խնդրում է բանալին, վերծանում ֆայլը և անձնական բանալին պահում է հիշողության մեջ այնքան, որքան անհրաժեշտ է։ Այդ պահից գաղտնաբառը ոչինչ չի պաշտպանում աշխատող սեսիայում՝ ոչ գործընթացի հիշողությունը, ոչ միջուկի արտապատկերը, ոչ հաճախորդին կցված վրիպազերծման սեսիան, և ոչ էլ բանալու օգտագործման ընթացքում արված մեքենայի պահուստային պատճենը։

Սա նույն սահմանն է, ինչ գաղտնաբառով SSH բանալու կամ գաղտնաբառերի կառավարչի բացված պահոցի դեպքում։ Այն բարձրացնում է հանգիստ վիճակում ֆայլը գողանալու արժեքը և ոչինչ չի անում ձեր օգտատիրոջ անունով աշխատող չարաշահող ծրագրի, հաճախորդից ստորագրություն պահանջող լիազորված հավելվածի կամ հիշողությունը կարդալ կարող ադմինիստրատորի դեմ։ Դիտեք այն որպես մեկ շերտ, ոչ որպես վերահսկողություն, որն անվտանգ է դարձնում բանալին անուշադիր թողնելը։

Ինչու է հարցումը նորից ու նորից վերադառնում

Ամեն վերակապակցման ժամանակ նորից հարցնող հաճախորդը պարտադիր չէ, որ կոտրված լինի։ Որոշ հաճախորդներ գաղտնաբառը պահում են սեսիայի քեշում, ոմանք՝ ՕՀ-ի բանալիների շղթայում, իսկ ոմանց կարելի է ուղղել օգնականի, որը տրամադրում է այն, ուստի վարքը կախված է հաճախորդից և դրա կարգավորումից, ոչ թե բանալու ֆայլից։

Եթե կրկնվող հարցումն է իրական բողոքը, բանալուց գաղտնագրումը հեռացնելուց առաջ ստուգեք հաճախորդի քեշավորման և նույնականացման ընտրանքները։ Գաղտնաբառը հեռացնելը պաշտպանված ֆայլը դարձնում է բաց տեքստով բանալի, և վերակապակցումը դառնում է լուռ՝ ձեր միակ հանգիստ վիճակի վերահսկողության հաշվին։ Ավելի լավ պատասխանը սովորաբար աջակցվող հավատարմագրերի պահոցն է՝ նույն ֆայլի թույլտվություններով, որոնք դուք միևնույն է օգտագործում էիք։

Կորուստը և բացահայտումը նույն վերանորոգումը չեն

Կորած գաղտնաբառը հնարավոր չէ վերականգնել վկայագրից։ Վկայագիրը հանրային նյութ է, որը անունը կապում է բանալու հետ. այն չի պարունակում վերադարձի ուղի դեպի անձնական բանալին և ոչ մի ակնարկ գաղտնաբառի մասին։ Գործնական տարբերակներն են բանալու լիազորված պահուստային պատճենը կամ օպերատորի սովորական գործընթացով թողարկված նոր ինքնությունը։ Ով առաջարկում է 'վերականգնել' գաղտնաբառը, առաջարկում է գուշակել այն։

Բացահայտումը այլ արձագանք է պահանջում։ Նույն բանալին նոր գաղտնաբառով վերագաղտնագրելը թողնում է բանալու նյութը անփոփոխ, ուստի այլ տեղ արդեն բացված պատճենը դեռ աշխատում է։ Վերանորոգումը հավատարմագրի չեղարկումն է կամ փոխարինումը. թողարկեք նոր բանալի և վկայագիր, տարածեք դրանք և թոշակի ուղարկեք հինը գործընկերոջ մոտ։ Քանի դա տեղի չի ունեցել, ֆայլի գաղտնաբառը փոխելը տնային աշխատանք է, ոչ թե զսպում։ Հին ֆայլը պահուստներից դուրս պահեք միայն նոր ինքնության աշխատելը հաստատելուց հետո, և գրանցեք, թե որ սերիական համարը կամ մատնահետքը փոխարինեց այն։