Ո՞ր OpenVPN փաթեթներն է պաշտպանում auth-ի digest-ը։
auth տարբերակը ծածկում է ավելի քիչ, քան ենթադրում է պրոֆիլը։ Անցեք ալիքը, AEAD դեպքը և կառավարման ալիքի պաշտպանությունը՝ նախքան digest-ի քաղաքականություն սահմանելը։
OpenVPN-ի digest-ների մասին վեճերի մեծ մասը սկսվում է սխալ փաթեթից։ Կարդալ auth SHA256 որպես «ընդունիր միայն այն գործընկերներին, որոնք առաջարկում են SHA256» առաջին բանն է, որ պետք է վերապրել։ Տարբերակը digest է անվանում որոշակի փաթեթների համար, և թե որ փաթեթներն են դրանք, կախված է ալիքից և այն բանից՝ արդյոք այդ ալիքը AEAD է։ Անցեք ներքևի չորս հարցերը հերթով՝ յուրաքանչյուրը նեղացնում է, թե ինչ կարող է նշանակել կարգավորումը ձեր տեղակայման մեջ։
Անվանեք այն ալիքը, որը պետք է պաշտպանի կարգավորումը
OpenVPN ունի կառավարման ալիք, որը կրում է TLS ձեռքսեղմման տրաֆիկը, և տվյալների ալիք, որը կրում է թունելի բեռը։ auth-ի digest-ը դեր ունի երկուսում էլ, բայց ոչ նույն դերը, և պրոֆիլը հազվադեպ է տարբերությունը տեսանելի դարձնում։ Գրի առեք, թե երկուսից որն եք փորձում սահմանափակել, նախքան կոնֆիգուրացիայի ֆայլին դիպչելը։
Ստորև բերված աղյուսակը կարճ տարբերակն է այն բանի, թե ինչպես է նույն տարբերակը հայտնվում յուրաքանչյուր համատեքստում։
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Ստուգեք՝ արդյոք տվյալների ալիքը AEAD է, նախքան դրա վրա հենվելը
Եթե բանակցված տվյալների ծածկագիրը AES-GCM կամ CHACHA20-POLY1305 է, տվյալների ալիքն ինքն է հաստատում իր իսկությունը, և առանձին digest-ը չի կատարում այն աշխատանքը, որը դուք գուցե պատկերացնում եք։ Երկուսն էլ AEAD կառուցվածքներ են, ուստի ամբողջականությունը ստեղծվում է նույն գործողությամբ, որը գաղտնագրում է բեռը։ Սա աստիճանի իջեցում չէ, բայց նշանակում է, որ «յուրաքանչյուր տվյալների փաթեթ HMAC-SHA256 է» հիմնավորմամբ քաղաքականությունը փաստացի սխալ է այդ թունելում։ Նախքան քաղաքականությունը վերաշարադրելը հաստատեք բանակցված արժեքը սերվերի մատյանում կամ հաճախորդի կարգավիճակի ելքում։
Ուսումնասիրեք փաստացի բանակցված ծածկագիրը, այլ ոչ թե պրոֆիլի ցանկը, քանի որ բանակցությունը կարող է ընկնել բազմության մեկ այլ անդամի վրա։ data-ciphers AES-256-GCM:AES-128-GCM բանակցային ցանկ է, և երկու գրառումներն էլ AEAD են, ուստի դրանցից ոչ մեկը բեռի պաշտպանության համար չի սպառում auth-ի digest-ը։
Կառավարման ալիքի պաշտպանությունը դիտարկեք որպես առանձին որոշում
tls-auth-ը HMAC է ավելացնում կառավարման ալիքի փաթեթներին և իր digest-ը վերցնում է auth կարգավորումից, դրա համար էլ AEAD թունելում դեռ կարող է իմաստալից digest կարգավորված լինել։ tls-crypt-ը այլ դասավորություն է՝ իր սեփական հաստատուն պաշտպանությամբ, ուստի մի ենթադրեք, որ այն ժառանգում է tls-auth-ի բոլոր հատկությունը։ Կարդացեք ձեր ընտրած մեխանիզմի փաստաթղթերը՝ ենթադրությունները նրանց միջև փոխանցելու փոխարեն։
Երկու գործընկերները պետք է համաձայնեն նաև դասավորության և բանալու ուղղության շուրջ։ Համընկնող digest-ը, բայց սխալ ուղղությամբ օգտագործված բանալու ֆայլը ստեղծում է ձեռքսեղմում, որը ձախողվում է պատճառներով, որոնք digest-ի կարգավորումը չի կարող բացատրել։
auth-ը առանձին պահեք ծածկագրերի բանակցությունից և վկայագրերից
Երեք կարգավորում անընդհատ շփոթվում են՝ auth-ի digest-ը, տվյալների ծածկագրերի ցանկը և վկայագրի ստորագրության ալգորիթմը։ Առաջինը փոխելը վկայագիր նորից չի թողարկում, չի ընտրում դրա ստորագրության digest-ը և չի ստեղծում օգտանուն-գաղտնաբառ մեթոդ։ Արձանագրության տարբերակների սահմանումները OpenVPN 2.6 աղբյուրներում նկարագրում են յուրաքանչյուրն իր բաժնում, ինչը օգտակար հիշեցում է, որ դրանք անկախ կարգավորիչներ են։
Երբ գործընկերը հրաժարվում է միանալ digest-ը փոխելուց հետո, պատճառը սովորաբար մյուս երկու կարգավորումներից մեկի անհամապատասխանությունն է։ Կարդացեք երկու ծայրերը նախքան դրանցից որևէ մեկը փոխելը։
Գրի առեք քաղաքականությունը և համեմատեք այն աշխատող կոնֆիգուրացիաների հետ
Նավատորմի մակարդակի հայտարարությունը պետք է նույն նախադասության մեջ հստակ նշի թույլատրելի տվյալների ալիքի ռեժիմները և ընտրված կառավարման ալիքի պաշտպանությունը։ Այդ նախադասությունը ստուգելի է՝ «մենք օգտագործում ենք SHA256»՝ ոչ։ Այնուհետև համեմատեք այն գործող սերվերի և հաճախորդի պրոֆիլների հետ, այլ ոչ թե պահոցում եղած ձևանմուշի։
Ավարտեք՝ արձանագրելով, թե յուրաքանչյուր թունել իրականում ինչ բանակցեց և որ մեխանիզմը հաստատեց նրա փաթեթների իսկությունը։ Պրոֆիլում տեսանելի auth տողը միայն կոնֆիգուրացիայի մտադրության ապացույց է, և մտադրությունը ստուգման ամենաէժան մասն է։