OCSP dhidi ya CRL: jinsi ukaguzi wa ubatilishaji kila mmoja unavyofanya kazi kwa kweli

Kimoja cha ukaguzi huu wa ubatilishaji hurejesha jibu lililosainiwa kuhusu cheti kimoja, na kingine hurejesha orodha iliyosainiwa ambayo unaipakua yote. Zote mbili zinakusudiwa kumwambia mthibitishaji kama kitambulisho bado kinaaminika, na zote mbili hushindwa kwa namna ambazo hazifanani kabisa. Mpangilio ulio hapa chini unafuata kile ambacho mwendeshaji hukutana nacho kwa kweli katika uzalishaji, kuanzia baiti zilizo kwenye waya hadi lango linalokataa muunganisho. Kuruka hatua ndiyo njia ambayo usambazaji huishia na sera ya ubatilishaji inayopatikana kwenye karatasi pekee.

Hatua 1: Kila ukaguzi hurejesha nini na hudumu kwa muda gani ukiwa unaweza kutumika

CRL huchapishwa kama kitu kimoja kilichosainiwa kinachofunika kila cheti ambacho mtoaji amekibatilisha, kwa hiyo mthibitishaji huichukua mara moja na kuutumia tena hadi nextUpdate ya orodha ipite. Jibu la OCSP ni jembamba zaidi: hujibu kwa cheti kimoja hasa na hubeba thisUpdate, producedAt na kwa kawaida nextUpdate pia. Tofauti hiyo huongoza kila kitu kingine. CRL iliyohifadhiwa kwenye akiba huzeeka kimya, kwa sababu faili bado inachanganuliwa na sahihi yake bado inathibitishwa, wakati jibu la OCSP lililoisha muda wake ni dhahiri halina thamani pale unaposoma mihuri yake ya muda.

Kwa hiyo uhifadhi wa akiba ndicho kitu cha kwanza kupanga: ni sehemu gani inayoshikilia nakala, na ni kikomo gani cha juu ambacho nakala hiyo inatii. Kwenye lango kikomo kinapaswa kuwa nextUpdate huku ukitoa ukingo wa usalama, kamwe si kile kichwa cha akiba cha HTTP kinachopendekeza kwa bahati. openssl crl -in issuer.crl -noout -lastupdate -nextupdate huchapisha tarehe zote mbili, na orodha ambayo nextUpdate yake tayari iko zamani inapaswa kuchukuliwa kama haipo na si kama ya zamani tu.

Hatua 2: Cheti huelekeza mteja wapi

Cheti la jani huwa na vidokezo viwili: kiendelezi cha eneo la usambazaji la CRL na ingizo la ufikiaji wa taarifa za mamlaka kwa OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints huchapisha cha kwanza, na cha pili kiko chini ya sehemu ya AIA ya openssl x509 -in client.pem -noout -text. Kiendelezi chochote ni kiashiria, si wajibu. Mteja asiyetekeleza kamwe ukaguzi wa ubatilishaji ataunganishwa vizuri kabisa na cheti ambacho viendelezi vyake vinamtaja mjibuji aliyekufa kwa mwaka mmoja.

Maeneo ya usambazaji mara nyingi hutaja mwenyeji wa ndani anayetatuliwa ndani ya sehemu moja ya mtandao tu, na baadhi ya wateja wa zamani hukataa URL za ldap kabisa. Jaribu ufikivu kutoka kwa mwenyeji anayemaliza handaki, si kutoka kwa kompyuta yako mwenyewe, kwa sababu hiyo ndiyo mtazamo pekee ambao kushindwa kwake kuna umuhimu wa kweli.

Hatua 3: Chagua fail-closed au fail-open kabla ya kukatika

Mjibuji asiyefikika au orodha iliyoisha muda wake hulazimisha uamuzi: kataa muunganisho, au ukubali na urekodi pengo. Amri ndogo ya verify ya OpenSSL hufanya chaguo kali kuwa wazi, kwa sababu kuongeza -crl_check hubadilisha CRL isiyopatikana kuwa unable to get certificate CRL na uthibitishaji ulioshindwa. Soft-fail katika stack nyingi si bendera hata kidogo, ni kukosekana kwa ukaguzi, na ndiyo sababu huwasilishwa kwa bahati mbaya.

Ili kuona tabia ambayo mteja anayo kwa kweli, ondoa mjibuji na uunganishe tena. Iwapo handaki bado linapanda, tafuta mstari wa kumbukumbu uliorekodi ukaguzi uliorukwa, kisha ujiulize kama mtu yeyote angesoma mstari huo wakati wa tukio. Muuzaji yule yule anaweza kutofautiana kwa itifaki: mteja wa IKEv2 na mteja wa OpenVPN kwenye mashine moja husoma mipangilio isiyohusiana.

Hatua 4: Thibitisha kuwa ukaguzi unafanyika mahali ambapo trafiki inakubaliwa

Tafuta mchakato unaomaliza au unaidhinisha muunganisho, kisha uulize mstari wa usanidi unaowasha ukaguzi wa ubatilishaji. Lango linalothibitisha mnyororo lakini haliulizi kamwe kuhusu ubatilishaji hutekeleza sera tofauti na ile iliyo kwenye nyaraka zako, na hakuna picha ya skrini ya mnyororo wa vyeti inayothibitisha kinyume. OpenVPN huandika chaguo hilo kama crl-verify; strongSwan huweka utafutaji wa CRL na OCSP chini ya usanidi wa CA, ambapo crl_uris au ocsp_uris huwekwa. Ikiwa huwezi kuelekeza kwenye chochote kati ya hivyo viwili, fikiria kuwa ukaguzi haupo.

Jibu la OCSP linahesabiwa tu wakati CA inayotoa imelisaini, au wakati mjibuji mwenye matumizi yaliyopanuliwa ya ufunguo OCSPSigning yaliyokabidhiwa na CA hiyo imelisaini, kwa hiyo jibu kutoka kwa huduma isiyohusiana halithibitishi chochote. Ikiwa unaendesha mjibuji mwenyewe, ufuatilie kama tegemezi gumu, kwa sababu huduma moja iliyokufa huingia kuwa kukatika kwa kila mteja wa fail-closed mara moja.

Hatua 5: Batilisha cheti kimoja kwa makusudi

Chukua cheti cha majaribio, kibatilishe kupitia chaneli ile ile ambayo uzalishaji hutumia, na uulize mjibuji moja kwa moja. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text inapaswa kuripoti Cert Status: revoked pamoja na muda wa ubatilishaji, na jibu good linamaanisha ubatilishaji wako haukufika kwa mjibuji ambao wateja wako wanauuliza. Kisha endesha openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem ili kuona uamuzi huo huo kupitia njia ya orodha. Soma mfuatano wa sababu badala ya msimbo wa kutoka, kwa sababu kukataliwa kwa ubatilishaji na hitilafu ya mnyororo zote huishia kwa kushindwa.

Hatua ambayo ina umuhimu wa kweli ni ya mwisho: unganisha tena ukiwa na wasifu wa zamani dhidi ya eneo halisi la utekelezaji na uthibitisha kuwa kukataliwa kunatokana na ubatilishaji. Kisha unganisha tena na cheti kipya, halali ili kuthibitisha kuwa hukuvunja msikilizaji pekee. Kufuta wasifu kwenye mteja hakuthibitishi chochote kuhusu uamuzi wa seva, na wala hufanyi hivyo utekelezaji uliofanikiwa wa openssl verify kwenye mashine ambayo haimalizi handaki kamwe. RFC 6960 hufafanua kile ambacho jibu la OCSP linaloafikiana linayo, ikiwa ni pamoja na thamani za hali ambazo jaribio hili husoma.