Հին P12-ը ձախողվում է OpenSSL 3-ում՝ սխալ գաղտնաբառ, թե՞ հնացած ծածկագիր
Տարբերե՛ք սխալ մուտքագրված գաղտնաբառը հին RC2 փաթեթից, որը OpenSSL 3-ը հրաժարվում է բացել, ապա նորից կնքի՛ր ֆայլը՝ չհեռացնելով բանալու պաշտպանությունը։
Ներմուծման երկխոսությունը վերցնում է ձեր գաղտնաբառը, պտտվում է մի պահ և հետո ասում, որ չի կարող կարդալ փաթեթը։ Այդ հաղորդագրության մեջ ոչինչ չի ասում՝ արդյոք դուք եք սխալ մուտքագրել գաղտնաբառը, թե ֆայլը կնքվել է ծածկագրով, որը հաճախորդն այլևս չի տրամադրում։ Սրանք տարբեր խափանումներ են՝ տարբեր լուծումներով, և սխալ ընտրությունը հանգեցնում է հաճախորդի տարբերակի իջեցման, ինչը միայն հետաձգում է որոշումը։ Նայելով, թե որ փուլում է հաճախորդը կանգ առնում, կարող եք դրանք տարբերել մոտ մեկ րոպեում։
Ինչ է տեղի ունենում երկխոսության և վկայագրերի ցանկի միջև
.p12 ֆայլը տարա է, ոչ վկայագիր։ Ներսում կա մեկ կամ մի քանի վկայագրի պարկ և մասնավոր բանալու պարկ, որը գաղտնագրված է ձեր գաղտնաբառից ստացված բանալիով, ինչպես նաև ամբողջ ֆայլի վրա MAC կոչվող ամբողջականության ստուգում։ Այն բացելը նշանակում է ստուգել այդ MAC-ը, վերծանել բանալու պարկը և վկայագիրը համապատասխանեցնել այն բանալուն, որը դուրս է գալիս դրանից։
Գաղտնաբառի խնդիրը գալիս է MAC փուլում։ Ծածկագրի խնդիրը գալիս է ավելի ուշ, երբ բանալու պարկը պետք է բացվի, և այն բացող կառուցվածքը ֆայլում նշված ալգորիթմի իրականացում չունի։
Երկրորդ դեպքը սովորական է ժամանակակից համակարգերում, քանի որ OpenSSL 3-ը հին ալգորիթմների խումբը տեղափոխել է ոչ պարտադիր legacy մատակարարի մեջ։ OpenSSL 1.x-ի արտահանած փաթեթները սովորաբար վկայագրերը կնքում էին 40-բիթանոց RC2-ով, իսկ մասնավոր բանալին՝ երեք բանալիով Triple DES-ով։ OpenSSL 3-ի լռելյայն կառուցվածքը դեռ ստուգում է MAC-ը ձեր ճիշտ գաղտնաբառով և հետո ձախողվում պարկի վրա, ուրեմն գաղտնաբառը երբեք սխալ չի եղել, և այն նորից մուտքագրելը ոչինչ չի փոխում։
Կարդացե՛ք տարան առանց բանալին դուրս գրելու
Խնդրե՛ք ձեր համակարգչի OpenSSL կառուցվածքին վերլուծել ֆայլը և կարդալ այն կետը, որտեղ այն հանձնվում է։ Առանց ելքային ֆայլի ստուգումը բանալին թողնում է սկավառակի վրա գաղտնագրված, և դա է այս քայլը համօգտագործվող հոսթում անվտանգ լինելու միակ պատճառը։
openssl pkcs12 -in vpn-identity.p12 -info -nooutՃիշտ գաղտնաբառով հին փաթեթի վրա սա տպում է պարկի հատկանիշները և հետո կանգ է առնում digital envelope routines::unsupported-ով։ Սխալ գաղտնաբառով դուք ստանում եք Mac verify error: invalid password? նախքան որևէ պարկ կարդալը։ Երկու հաղորդագրությունները ցույց են տալիս հակառակ ուղղություններով, և դա հենց այն տեղեկությունն է, որը հաճախորդը թաքցրել էր։
Եթե խափանումը չաջակցվող ալգորիթմինն է, գործարկե՛ք նույն հրամանը կրկին՝ ավելացնելով -legacy և ոչինչ այլ չփոխելով։ Այդ դրոշը legacy մատակարարին բեռնում է միայն այդ մեկ պրոցեսի համար։ Այն VPN հաճախորդին չի ստիպում վերլուծել հին փաթեթները, չի դիպչում համակարգային կրիպտոյական քաղաքականությանը, և դա չափում է, ոչ թե վերանորոգում, որովհետև ֆայլը դեռ պետք է փոխարինվի։
Որ սխալը որ փուլն է նշանակում
Կարճ աղյուսակը առանձին է պահում երեք արդյունքները, և ձևակերպումն ավելի կարևոր է, քան այն, թե որտեղ հայտնվեց երկխոսությունը։
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data-ի կամ header too long-ի նման տեքստը չի պատկանում առաջին երկու խմբերից ոչ մեկին։ Սա ձևաչափի խնդիր է՝ .pem վերանվանված DER ֆայլ, խմբագրիչի կողմից փչացված պատճեն, որը վերաշարադրել է տողերի վերջավորությունները, կամ թերի ներբեռնում։ Համեմատե՛ք ստուգիչ գումարը թողարկողի ուղարկածի հետ նախքան ծածկագրերին նայելը։
Mac verify error-ը դիտե՛ք միայն որպես գաղտնաբառի մասին ապացույց։ Դա նշանակում է, որ ձեր մուտքագրածից հաշվարկված MAC-ը չի համապատասխանում պահված արժեքին, ինչը լինում է տառասխալից, նախորդ ներմուծումից քեշավորված գաղտնաբառից կամ այլ գաղտնաբառով վերաարտահանված ֆայլից։ Այն ոչինչ չի ասում ներսի ալգորիթմների հնացած լինելու մասին։
Կառուցե՛ք փաթեթ, որը հաճախորդը իսկապես կարող է բացել
Երբ legacy վերլուծիչը հաստատի, որ ֆայլը կարգին է, տևական լուծումը փոխարինումն է, որի ալգորիթմներին թիրախ հաճախորդը աջակցում է՝ AES-256-CBC բանալու և վկայագրի պարկերի համար, PBKDF2 SHA-256-ով՝ ածանցման համար, և SHA-256՝ MAC-ի համար։ Ձեր PKI ադմինիստրատորը կարող է դա արտահանել նույն բանալի նյութից, և ներսի վկայագիրը մնում է այն, ինչին ձեր սերվերներն արդեն վստահում են։
Երբ ստիպված եք տեղում փոխարկել, խնդրե՛ք pkcs12 գործիքին նորից կնքել պարկերը՝ նախապես դրանք դատարկելու փոխարեն։ Երկու գաղտնաբառներն էլ պահե՛ք shell-ի պատմությունից դուրս՝ կարդալով դրանք ֆայլից։
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passՀաջող փոխարկումը ոչինչ չի ասում ժամկետի, բանալու օգտագործման, մասնավոր բանալու համապատասխանության կամ այն մասին, թե արդյոք սերվերը վստահում է թողարկող շղթային։ Վերափաթեթավորումը տրանսպորտի փոփոխություն է, ոչ թե նորացում, և դրանցից յուրաքանչյուրը դեռ իր ստուգումն է պահանջում։
Բաց թողե՛ք ցանկացած բաղադրատոմս, որը գրում է անպաշտպան միջանկյալ բանալի կամ դատարկ ելքային գաղտնաբառ, միայն այն պատճառով, որ հաճախորդը հետո ընդունել է ֆայլը։ Պաշտպանությունը հեռացված ընթեռնելի փաթեթը ավելի վատ արդյունք է, քան այն ներմուծման խափանումը, որով սկսել եք։
Հաստատե՛ք, որ հաճախորդը ներմուծել է հենց ձեր կառուցած ֆայլը
Տերմինալում մաքուր վերլուծությունը ապացուցում է, որ տարան վավեր է։ Այն չի ապացուցում, որ հաճախորդն ընտրել է այն, քանի որ մնացած պրոֆիլը կարող է շարունակել ցույց տալ հին ֆայլին, և որոշ հաճախորդներ ներմուծված ինքնությունը պահում են քեշում ձեր չընտրած անվան տակ։
Տպե՛ք այն ինքնությունը, որը պատրաստվում եք ներմուծել, և համեմատե՛ք այն բանի հետ, ինչ հաճախորդը ցույց է տալիս վկայագրերի իր տեսքում։
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256Նախ հեռացրե՛ք հնացած պրոֆիլի գրառումը, ապա ներմուծե՛ք։ Եթե հաճախորդը գրանցում է բեռնված սուբյեկտը կամ մատնահետքը, համապատասխանեցրե՛ք այն վերևի տողին, իսկ եթե այն ցույց է տալիս միայն ընկերական անուն, փոխարենը ստուգե՛ք ժամկետի ավարտի ամսաթիվը, քանի որ այն նույն թողարկողի մեկ այլ վկայագրի հետ շփոթելը ավելի դժվար է։
PKCS12 տեղեկատուն թվարկում է այստեղ օգտագործված մատակարարի, գաղտնաբառի և ելքի ընտրանքները։ Խնդիրն այն է, որ legacy մատակարարը մնա հաճախորդի միջավայրից դուրս՝ չափե՛ք դրանով, առաքե՛ք առանց դրա և մասնավոր բանալին թողե՛ք պաշտպանված սկավառակի վրա։