Մեկ հին peer պարտադրում է TLS 1.0՝ սահմանափակեք բացառությունը, ոչ թե հոսթը

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

Բաժանեք խափանումը երկուսի՝ նախքան հրահանգը խմբագրելը

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Ավելի թույլ նվազագույն շեմի ազնիվ տեղը երկրորդ լսիչն է

Երբ սարքը կանգ է առնում TLS 1.0-ի վրա՝ մինչև 2.5 տվյալների ալիքով, սերվերը պետք է առաջարկի կառավարման ալիքի ավելի ցածր նվազագույն շեմ և տվյալների գաղտնագիր, որը հին հաճախորդը ճանաչում է։ Պահուստային հրահանգը գոյություն ունի հենց այդ peer-ի համար, մինչդեռ գաղտնագրերի ցանկը ժամանակակից հաճախորդներին պահում է ժամանակակից հավաքածուների վրա։ Երկու հրահանգներն էլ պատկանում են լսիչին, ոչ թե օգտատիրոջը կամ կապին, և ոչ մի ընտրանք յուրաքանչյուր հաճախորդի համար հետագայում չի նեղացնում դրանք։ Այդ պատճառով հիմնական պորտում մեկ հին սարքը որոշում է յուրաքանչյուր peer-ի մասին, որը կիսում է այն։

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

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Ինչ է իրականում կոտրում մատակարարի հին վկայականը

Ստուգման սխալը բացակայող դերակապն է. առանց դրա հաճախորդը կընդունի ցանկացած վկայական, որը շղթայվում է վստահելի CA-ի, անկախ այն բանից՝ այն տրվել է սերվերի համար, թե ոչ։ Նախ կապեք վկայականը սերվերի դերին, և կապը համարեք պահանջ, ոչ թե կարգավորման կոճակ։ Իսկական վկայականի խնդիր ունի միայն այն պրոֆիլը, որը այդ քայլից հետո դեռ ձախողվում է։

Մատակարարի հին վկայականը, որի բանալու չափը կամ ստորագրության ալգորիթմն այլևս չի բավարարում OpenSSL-ի լռելյայն քաղաքականությանը, հանդիսանում է կառավարման ալիքում անվտանգության մակարդակի սահմանափակ փոփոխության դեպք։ Մակարդակն այնտեղ իջեցնելը չի անջատում ստուգումը, և այն երբեք չպետք է զուգակցվի դատարկ CA-ի, անջատված ստուգման կարգավորման կամ չստուգված հոսթանվան հետ։ Տողը պահեք այն միակ պրոֆիլի ներսում, որին այն պետք է. թուլացված OpenSSL կարգավորումը գլոբալ արտահանելը նույն թուլացումը կտա մեքենայի յուրաքանչյուր ծրագրի։

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Կարդացեք բանակցված արժեքները, ոչ թե ցուցանակը

4 մանրամասնության մակարդակում երկու կողմերն էլ տպում են կառավարման ալիքի TLS տարբերակը և գաղտնագիրը, որոնց շուրջ համաձայնել են, և սեսիայի տվյալների գաղտնագիրը։ Կարդացեք այդ տողերը, ոչ թե մեկնարկի ցուցանակը, որը հաղորդում է հաջողության մասին, ոչ թե դրա պայմանների։ Ապա նորից միացրեք ժամանակակից հաճախորդին հիմնական լսիչին և հաստատեք, որ այն դեռ վայրէջք է կատարում ժամանակակից հավաքածուի վրա, որովհետև ընդհանուր կարգավորում ներթափանցած բացառությունն առաջինը հենց այստեղ է երևում։ Ձեր պատճենած արժեքները դառնում են հաջորդ վերանայման ելակետը։

Փորձարկեք հին սարքը առանձին. այն պետք է միանա և լինի մատյաններում միակ սեսիան, որը ցույց է տալիս ավելի թույլ պարամետրերը։ Եթե երկրորդ peer-ը նույնպես բանակցում է հին հավաքածուն, բացառությունն ավելի լայն է, քան նախատեսված էր, և լսիչի բաժանումը իրականում չի կատարվել։ Գրանցեք երկու դիտարկումներն էլ, ոչ միայն եզրակացությունը։

Յուրաքանչյուր բացառություն պահանջում է սեփականատեր և ամսաթիվ

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

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