Կարո՞ղ է RSA սերտիֆիկատը աշխատել dh none-ի հետ OpenVPN-ում։

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

Շփոթությունը սովորաբար գալիս է միգրացիայի ուղեցույցի հետ։ Այն ասում է փոխարինել DH պարամետրերի ֆայլը dh none-ով, ընթերցողը նկատում է, որ սերտիֆիկատը էլիպտիկ կորի սերտիֆիկատ չէ, և երկու փաստերը դիտարկվում են որպես հակասություն։

Ինչու երկու կարգավորումները կապված են թվում

OpenVPN-ի հին կոնֆիգուրացիան պահանջում էր DH պարամետրերի ֆայլ, քանի որ վերջավոր դաշտի Diffie-Hellman-ին անհրաժեշտ են տիրույթի պարամետրեր, որոնց շուրջ երկու կողմերը համաձայն են։ dh հրահանգը մատնանշում էր այդ ֆայլը։ Երբ տեղակայումը անցնում է ECDH-ի, պարամետրերը փոխարենը գալիս են անվանված կորից, և ֆայլն այլևս պետք չէ, ինչն արտահայտում է dh none-ը։

Սերտիֆիկատները առանձին առանցք են։ Դրանք կրում են հանրային բանալի և ստորագրություն, որոնք ապացուցում են սերվերի ինքնությունը, և այդ բանալին կարող է լինել RSA կամ էլիպտիկ կոր՝ անկախ նրանից, թե ինչպես է համաձայնեցվում սեսիայի բանալին։ Ձեռքսեղմումը, որն օգտագործում է ECDHE բանալու համաձայնության համար և RSA՝ նույնականացման համար, սովորական է և լայնորեն տարածված։

Անվանակարգը վատթարացնում է համընկնումը։ Էլիպտիկ կորը հանդիպում է ինչպես ECDHE, այնպես էլ ECDSA փաթեթների անվանումներում, ուստի հեշտ է ենթադրել, որ կոր նշող ցանկացած կապ պետք է ներառի կորի սերտիֆիկատ։ Այդպես չէ։

Ինչպես ճիշտ կարդալ TLS 1.2 փաթեթի անվանումը

Վերցրեք ECDHE-RSA-AES256-GCM-SHA384-ը։ Առաջին նշանը բանալիների փոխանակման ընտանիքն է՝ ժամանակավոր էլիպտիկ կորի Diffie-Hellman։ Երկրորդը նույնականացման ընտանիքն է՝ RSA։ Մնացածը նկարագրում է գրառումների պաշտպանությունը և ձեռքսեղմման մեջ օգտագործվող հեշը։

ECDHE-ECDSA փաթեթը օգտագործում է նույն բանալիների փոխանակման ընտանիքը այլ նույնականացման մեթոդով, ուստի այն պահանջում է էլիպտիկ կորի սերտիֆիկատ։ DHE-RSA փաթեթը օգտագործում է վերջավոր դաշտի ժամանակավոր Diffie-Hellman՝ RSA նույնականացմամբ, և այդ մեկին իսկապես պետք են DH պարամետրեր։

Կարդացեք փաթեթի անվանումը ձախից աջ և յուրաքանչյուր մասը վերագրեք իր աշխատանքին։ Երբ նշանները բաժանվեն, հարցը «արդյո՞ք իմ սերտիֆիկատը համապատասխանում է dh none-ին» փոխվում է «արդյո՞ք իմ սերվերը թույլ է տալիս փաթեթ, որի բանալիների փոխանակմանը DH ֆայլ պետք չէ»։

Ինչն է իրականում անջատում dh none-ը

dh none-ը սերվերին ասում է չբեռնել վերջավոր դաշտի DH պարամետրերի ֆայլ։ Այն չի անջատում նույնականացումը, սերտիֆիկատների վավերացումը կամ ինքը TLS-ը։ Սակայն այն պահանջում է, որ համաձայնեցված բանալիների փոխանակումը լինի այնպիսին, որին այդ պարամետրերը պետք չեն, ինչը գործնականում նշանակում է ECDHE փաթեթ կամ TLS 1.3 ձեռքսեղմում։

Հենց այդ պահանջից է գալիս խափանումը։ Եթե սերվերի TLS գաղտնագրման քաղաքականությունը սահմանափակված է DHE փաթեթներով, կամ հաճախորդը առաջարկում է միայն դրանք, պարամետրերի ֆայլը հեռացնելը չի թողնում օգտագործելի բանալիների փոխանակման մեթոդ, և ձեռքսեղմումը ձախողվում է։ Սխալը սովորաբար հայտնվում է կառավարման ուղիների ձեռքսեղմման ընթացքում՝ նախքան օգտվողի ցանկացած նույնականացում։ Կարդացեք գաղտնագրերի ցանկը նախքան բացակայող ֆայլին մեղադրելը։

Էլիպտիկ կորի կողմում կորը ընտրում է սերվերի TLS կոնֆիգուրացիան, և OpenVPN-ը հին ճյուղերում առաջարկում է այն ընտրելու տարբերակ։ TLS 1.3-ը խմբի բանակցությունը կատարում է արձանագրության ներսում և ընդհանրապես չի դիմում DH ֆայլին։

dh none-ը ինքնին անվտանգության իջեցում չէ։ Փոխանակման ուժգնությունն այնուհետև կախված է իրականում համաձայնեցված կորից և փաթեթից, դրա համար էլ հաջորդ քայլը բացակայող ֆայլին նայելը չէ, այլ այն, թե ինչ են ընտրել կողմերը։

Հաստատել բանակցությունը խմբագրելուց առաջ

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

Եթե այն ցույց է տալիս TLS 1.2՝ ECDHE-RSA փաթեթով և RSA սերտիֆիկատով, համակցությունը հենց այն է, ինչ սպասում է dh none-ը, և վերանորոգելու ոչինչ չկա։ Եթե այն ցույց է տալիս DHE փաթեթ կամ ձեռքսեղմման ձախողում առանց ընդհանուր գաղտնագրի, լուծումը գաղտնագրման քաղաքականության կամ հաճախորդի հնարավորությունների մեջ է, ոչ թե սերտիֆիկատում։

Փորձարկեք ամենահին հաճախորդը, որին պատրաստվում եք աջակցել, քանի որ ընթացիկ հաճախորդը կարող է համաձայնություն ձեռք բերել TLS 1.3-ի շուրջ, մինչ ավելի հինը սահմանափակված է TLS 1.2 փաթեթներով։ Եթե ամենահին հաճախորդը համընկնում չունի, կա՛մ լայնացրեք թույլատրված փաթեթները, կա՛մ թարմացրեք այդ վերջնակետը։

Մի՛ անջատեք սերտիֆիկատի ստուգումը ձեռքսեղմման ձախողումը շրջանցելու համար։ Ձախողումը ձեզ ասում է, որ կողմերը չեն կարողացել համաձայնել բանալիների փոխանակման շուրջ, և ստուգումն անջատելը հանում է ինքնության երաշխիքը՝ չլուծելով համաձայնությունը։

Ստուգաթերթ. արդյո՞ք սերտիֆիկատը RSA է, արդյո՞ք ECDHE փաթեթը թույլատրված է, արդյո՞ք մատյանը ցույց է տալիս այդ փաթեթը, և արդյո՞ք ամենահին աջակցվող հաճախորդը նույնպես համաձայնում է դրա շուրջ։ Եթե բոլոր չորսը այո են, dh none-ը կատարում է իր աշխատանքը։