OCSP-ն ընդդեմ CRL-ի՝ ինչպես է իրականում աշխատում յուրաքանչյուր չեղարկման ստուգում

Այս երկու չեղարկման ստուգումներից մեկը վերադարձնում է ստորագրված պատասխան մեկ վկայականի մասին, իսկ մյուսը՝ ստորագրված ցանկ, որը ներբեռնում եք ամբողջությամբ։ Երկուսն էլ պետք է ստուգողին ասեն՝ արդյոք հավատարմագիրը դեռ վստահելի է, և երկուսն էլ ձախողվում են այնպես, որ բոլորովին նման չեն իրար։ Ստորև բերված հերթականությունը հետևում է այն բանին, ինչի օպերատորն իրականում հանդիպում է արտադրության մեջ՝ սկսած լարով անցնող բայթերից և ավարտվելով կապը մերժող դարպասով։ Քայլը բաց թողնելը հենց այն ձևն է, որով տեղակայումը մնում է մի չեղարկման քաղաքականությամբ, որը գոյություն ունի միայն թղթի վրա։

Քայլ 1: ինչ է վերադարձնում յուրաքանչյուր ստուգումը և որքան ժամանակ է այն օգտագործելի մնում

CRL-ը հրապարակվում է որպես մեկ ստորագրված օբյեկտ, որն ընդգրկում է թողարկողի կողմից չեղարկված բոլոր վկայականները, ուստի ստուգողը վերցնում է այն մեկ անգամ և կրկին օգտագործում, մինչև ցանկի nextUpdate-ը անցնի։ OCSP պատասխանն ավելի նեղ է՝ այն պատասխանում է ուղիղ մեկ վկայականի համար և կրում է thisUpdate, producedAt և սովորաբար նաև nextUpdate։ Այդ տարբերությունն է, որ ղեկավարում է մնացած ամեն ինչ։ Քեշավորված CRL-ը լուռ հնանում է, որովհետև ֆայլը դեռ վերլուծվում է, և դրա ստորագրությունը դեռ ստուգվում է, մինչդեռ ժամկետանց OCSP պատասխանն ակնհայտորեն անարժեք է այն պահին, երբ կարդում եք դրա ժամանակային դրոշմանիշերը։

Ուստի քեշավորումն առաջին բանն է, որ պետք է ամրագրել՝ ո՛ր բաղադրիչն է պահում պատճենը, և ի՛նչ վերին սահմանի է ենթարկվում այդ պատճենը։ Դարպասի վրա սահմանը պետք է լինի nextUpdate-ը հանած անվտանգության լուսանցք, երբեք ոչ թե այն, ինչ պատահաբար առաջարկում է HTTP քեշի վերնագիրը։ openssl crl -in issuer.crl -noout -lastupdate -nextupdate տպում է երկու ամսաթվերը, և ցանկ, որի nextUpdate-ն արդեն անցյալում է, պետք է դիտարկել որպես բացակայող, այլ ոչ թե պարզապես հին։

Քայլ 2: ուր է վկայականը ուղղորդում հաճախորդին

Տերևային վկայականը սովորաբար կրում է երկու հուշում՝ CRL բաշխման կետի ընդլայնում և OCSP-ի համար մարմնի տեղեկատվության հասանելիության գրառում։ openssl x509 -in client.pem -noout -ext crlDistributionPoints տպում է առաջինը, իսկ երկրորդը գտնվում է openssl x509 -in client.pem -noout -text-ի AIA բաժնում։ Ընդլայնումներից յուրաքանչյուրը ցուցիչ է, ոչ պարտավորություն։ Հաճախորդը, որը երբեք չի իրականացնում չեղարկման ստուգում, լիովին լավ կմիանա վկայականի, որի ընդլայնումները նշում են պատասխանողի, որը մեռած է արդեն մեկ տարի։

Բաշխման կետերը հաճախ նշում են ներքին հոսթ, որը լուծվում է միայն մեկ ցանցային սեգմենտի ներսում, և որոշ հին հաճախորդներ ուղղակիորեն մերժում են ldap URL-ները։ Փորձարկեք հասանելիությունը այն հոսթից, որը վերջացնում է թունելը, ոչ թե ձեր սեփական նոութբուքից, որովհետև դա է միակ տեսանկյունը, որի ձախողումն իսկապես նշանակություն ունի։

Քայլ 3: ընտրեք fail-closed կամ fail-open մինչև ընդհատումը

Անհասանելի պատասխանողը կամ ժամկետանց ցանկը պարտադրում են որոշում՝ մերժել կապը, կամ ընդունել այն և գրանցել բացը։ OpenSSL-ի verify ենթահրամանը հստակեցնում է խիստ ընտրությունը, որովհետև -crl_check ավելացնելը անհասանելի CRL-ը դարձնում է unable to get certificate CRL և ձախողված ստուգում։ Փափուկ ձախողումը շատ ստեկերում ամենևին էլ դրոշակ չէ, այլ ստուգման բացակայություն, և հենց դրա համար է այն պատահաբար հայտնվում արտադրության մեջ։

Որպեսզի տեսնեք, թե հաճախորդն իրականում ինչ վարք ունի, հեռացրեք պատասխանողին և նորից միացեք։ Եթե թունելը դեռ բարձրանում է, գտեք այն մատյանի տողը, որը գրանցել է բաց թողնված ստուգումը, ապա հարցրեք՝ արդյոք ինչ-որ մեկը կկարդա՞ այդ տողը միջադեպի ժամանակ։ Նույն մատակարարը կարող է տարբերվել ըստ արձանագրության. միևնույն մեքենայի վրա IKEv2 հաճախորդը և OpenVPN հաճախորդը կարդում են իրար հետ կապ չունեցող կարգավորման բանալիներ։

Քայլ 4: ապացուցեք, որ ստուգումն աշխատում է այնտեղ, որտեղ թրաֆիկը թույլատրվում է

Գտեք այն գործընթացը, որը վերջացնում կամ լիազորում է կապը, ապա հարցրեք նրան այն կազմաձևի տողի մասին, որը միացնում է չեղարկման ստուգումը։ Դարպասը, որը վավերացնում է շղթան, բայց երբեք չի հարցնում չեղարկման մասին, կիրառում է այլ քաղաքականություն, քան ձեր փաստաթղթերում է, և վկայականների շղթայի ոչ մի սքրինշոթ չի ապացուցում հակառակը։ OpenVPN-ը այդ ընտրանքը գրում է crl-verify տեսքով. strongSwan-ը CRL-ի և OCSP-ի որոնումները պահում է CA կազմաձևի տակ, որտեղ սահմանվում են crl_uris կամ ocsp_uris։ Եթե չեք կարող մատնանշել դրանցից ոչ մեկին, ենթադրեք, որ ստուգումը բացակայում է։

OCSP պատասխանը վավեր է միայն այն դեպքում, երբ այն ստորագրել է թողարկող CA-ն, կամ երբ այն ստորագրել է պատասխանող, որն ունի այդ CA-ի կողմից պատվիրակված OCSPSigning ընդլայնված բանալու օգտագործումը, ուստի անկապ ծառայությունից ստացված պատասխանը ոչինչ չի ապացուցում։ Եթե դուք ինքներդ եք վարում պատասխանողին, վերահսկեք այն որպես կոշտ կախվածություն, որովհետև մեկ մեռած ծառայություն միանգամից դառնում է ընդհատում յուրաքանչյուր fail-closed հաճախորդի համար։

Քայլ 5: դիտավորյալ չեղարկեք մեկ վկայական

Վերցրեք փորձնական վկայական, չեղարկեք այն նույն ալիքով, որն օգտագործում է արտադրությունը, և ուղղակիորեն հարցրեք պատասխանողին։ openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text-ը պետք է հաղորդի Cert Status: revoked՝ չեղարկման ժամանակի հետ միասին, իսկ good պատասխանը նշանակում է, որ ձեր չեղարկումը չի հասել այն պատասխանողին, որին հարցնում են ձեր հաճախորդները։ Ապա գործարկեք openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem-ը՝ նույն որոշումը ցանկի ուղով տեսնելու համար։ Կարդացեք պատճառի տողը, այլ ոչ թե ելքի կոդը, որովհետև չեղարկման մերժումը և շղթայի սխալը երկուսն էլ ավարտվում են ձախողմամբ։

Քայլը, որն իսկապես նշանակություն ունի, վերջինն է՝ նորից միացեք հին պրոֆիլով իրական կիրառման կետի դեմ և հաստատեք, որ մերժումը գալիս է չեղարկումից։ Ապա նորից միացեք թարմ, վավեր վկայականով՝ ապացուցելու, որ դուք պարզապես չեք կոտրել լսողին։ Կլիենտի վրա պրոֆիլը ջնջելը ոչինչ չի ապացուցում սերվերի որոշման մասին, և դա չի անում նաև հաջող openssl verify գործարկումը մի մեքենայի վրա, որը երբեք չի վերջացնում թունել։ RFC 6960-ը սահմանում է, թե ինչ է պարունակում համապատասխան OCSP պատասխանը, ներառյալ կարգավիճակի արժեքները, որոնք կարդում է այս թեստը։