Այս սխալը գալիս է գաղտնաբառի հարցումից առաջ, և դա է օգտակար մասը. դեռ ոչինչ չի նույնականացվել, ուստի խնդիրը հավատարմագրերը չեն։ Linux-ում նույն AnyConnect երկխոսությունը կարող է գալ հին արձանագրության տարբերակից, 1024-բիթանոց բանալիների փոխանակման խմբից կամ ծածկագրման հավաքածուից, որը համակարգի գաղտնագրային քաղաքականությունը մերժում է։ Ես այն վերացրել եմ երեք տարբեր եղանակով երեք մեքենաների վրա, և այդ լուծումներին տարբերում է ազդեցության շրջանակը, ոչ թե հնարամտությունը։ Յուրաքանչյուրը արդարացված է ճիշտ տեղում և վատ լռելյայն ամեն այլ տեղ։

Կարդացեք հաղորդագրությունը նախքան քաղաքականությանը դիպչելը

Պահեք երկխոսության ճշգրիտ տողը։ Տարբերակի բողոքը ցույց է տալիս արձանագրության շերտը, վկայագրի բողոքը՝ վստահությունը կամ անվանումը, իսկ ձախողված մուտքը՝ հավատարմագրերը։ TLS 1.0, 1024-բիթանոց DHE խումբ, AES-256-CBC և SHA-1 ստորագրություն առաջարկող դարպասը կարող է ունենալ լիովին վավեր վկայագիր և այնուամենայնիվ մերժվել ժամանակակից քաղաքականությամբ՝ նախքան ձեր հավատարմագրերի ուղարկվելը։

Ստուգեք վերջնակետը համակարգի OpenSSL-ով՝ օգտագործելով իրական հոսթի անունը և այն պորտը, որն օգտագործում է հաճախորդը։

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com-ի ձախողումը, մինչ -tls1 -cipher DEFAULT@SECLEVEL=0-ը հաջողվում է, նշանակում է, որ սահմանը տարբերակն ու բանալու չափը միասին են։ Եթե առաջին հրամանը հաղորդում է փոքր DH բանալու մասին, այլ ոչ արձանագրության զգուշացման, տարբերակը նորմալ է և միայն խումբն է ուշադրություն պահանջում։ Երբեք ստուգման մեջ չդնեք մասնավոր բանալի կամ գաղտնաբառ։

Տարբերակ 1. թուլացնել ամբողջ հոսթը գաղտնագրային քաղաքականությամբ

Fedora-ում և RHEL 8 և 9-ում update-crypto-policies --set LEGACY-ը իջեցնում է OpenSSL-ի համակարգային քաղաքականությունը, իսկ update-crypto-policies --show-ը հաստատում է, թե որն է ակտիվ։ Սա սովորաբար վերականգնում է թունելը, սակայն քաղաքականությունը կարդացվում է գործընթացի մեկնարկին, ուստի նախքան կրկին փորձարկելը վերագործարկեք հաճախորդը և նրա ստեղծած ցանկացած օժանդակ գործընթաց։ Այն նաև թույլ է տալիս հին արձանագրություններ և ավելի թույլ խմբեր մեքենայի յուրաքանչյուր TLS հաճախորդի համար՝ հարևան պատուհանի բրաուզերից մինչև միջուկը թարմացնող փաթեթների կառավարիչը։

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

Debian-ը և Ubuntu-ն այս ամենի համար մեկ անջատիչ չունեն։ Համարժեքը /etc/ssl/openssl.cnf-ի խմբագրումն է, որը համակարգի լռելյայն բաժնում սահմանում է ավելի ցածր MinProtocol և CipherString = DEFAULT@SECLEVEL=0։ Նույն շրջանակը, այլ ֆայլ, մի փոքր ավելի հեշտ է աչքից կորցնել թողարկման թարմացման ժամանակ։

Տարբերակ 2. մեկ կարգավորման ֆայլ մեկ հաճախորդի համար

Գործընթացի համար OpenSSL կարգավորումը փոփոխությունը պահում է մեկ գործընթացի ծառի ներսում, բայց միայն այն դեպքում, երբ ֆայլը միացված է այնպես, ինչպես սպասում է գրադարանը։ ssl_conf բաժինը անվանելը բավարար չէ. OpenSSL-ը կարդում է վերին մակարդակի openssl_conf բանալին, հետևում դրան մինչև նախաձեռնման բաժին և միայն այդ ժամանակ հասնում SSL լռելյայններին։

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

Ուղղեք OPENSSL_CONF-ը այդ ֆայլին և գործարկեք VPN հաճախորդը փաթաթանի միջոցով, որը արտահանում է այն։ Հոսթի վրա մնացած ամեն ինչ պահպանում է լռելյայն քաղաքականությունը, և դա այն հատկությունն է, որը կարևոր է, երբ գալիս է համապատասխանության հարցը։ Հաստատեք, որ ֆայլն իսկապես ուժի մեջ է, նախքան դարպասին մեղադրելը. OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1-ը պետք է թվարկի TLS 1.0 ծածկագրեր, իսկ դատարկ արդյունքը նշանակում է, որ շղթան կոտրված է, և հաճախորդը լուռ պահել է համակարգի լռելյայնները։

Ֆայլը զգայուն է տարբերակի նկատմամբ։ OpenSSL 1.1.1-ը և 3.x-ը ընդունում են նույն բաժինների անվանումները, սակայն մատակարարների շուրջ հրահանգների մշակումը փոխվել է 3.x-ում, ուստի ստուգեք հաճախորդի սեփական մատյանով և փորձնական ձեռքսեղմումով, այլ ոչ թե ենթադրեք, որ ֆայլը կարդացվել է։ Բաժնի անվան մեջ տպագրական սխալը ձախողվում է բաց, և հաճախորդը լուռ օգտագործում է համակարգի լռելյայնները։

Սահմանափակումը ծածկույթն է։ Ամեն ինչ, որ կապված է GnuTLS-ի կամ NSS-ի հետ, անտեսում է OPENSSL_CONF-ը, ինչպես նաև ցանկացած օժանդակ գործընթաց, որը հաճախորդը գործարկում է առանց միջավայրը ժառանգելու։ Ստուգեք ldd-ով, թե կատարվող ֆայլը իրականում որ TLS գրադարանին է կապված, նախքան փաթաթանը կառուցելը, որովհետև պատասխանը որոշում է՝ այս տարբերակը ընդհանրապես գոյություն ունի՞։

Տարբերակ 3. մեկանգամյա VM կամ կոնտեյներ

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

Այն դեռ ցանցային մեքենա է, ուստի սահմանափակեք դրա հասանելիությունը և հեռու պահեք ընդհանուր զննարկումից։ Սպասարկման ծախսը կարկատելու ևս մեկ պատկեր է, ինչը իրական է, բայց սահմանափակ և տեսանելի, ի տարբերություն նոթբուքի վրա մոռացված LEGACY դրոշի։

Ինչ է ձեզ թողնում համեմատությունը

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

Կայուն ուղղումը պատկանում է սարքին. TLS 1.2 կամ ավելի նոր, առնվազն 2048 բիթանոց խումբ, AEAD ծածկագիր և ժամանակակից ստորագրությամբ վկայագիր։ Խնդրեք այդ փոփոխությունը սարքի սեփականատիրոջից, ապա հաստատեք բանակցված տարբերակը և ծածկագիրը հաճախորդի մատյանում։ Գրեք բացառությունը հոսթի, դարպասի, բանակցված արձանագրության, հաստատողի և ժամկետի հետ միասին, քանի որ հենց այդ գրառումն է խանգարում ժամանակավոր լուծմանը դառնալ լռելյայն։

Առնչվող հոդվածներ