OCSP laban sa CRL: paano talaga gumagana ang bawat pagsusuri ng pagpapawalang-bisa

Ang isa sa dalawang pagsusuring ito ng pagpapawalang-bisa ay nagbabalik ng pinirmahang sagot tungkol sa isang sertipiko, at ang isa ay nagbabalik ng pinirmahang listahang isina-download mo nang buo. Pareho silang naglalayong sabihin sa tagapagpatunay kung mapagkakatiwalaan pa ang isang kredensyal, at pareho silang nabibigo sa paraang hindi talaga magkatulad. Ang pagkakasunod-sunod sa ibaba ay sumusunod sa aktwal na nararanasan ng operator sa produksiyon, mula sa mga byte sa kable hanggang sa gateway na tumatanggi sa koneksiyon. Ang paglaktaw ng isang hakbang ang paraan para mauwi ang isang deployment sa patakarang pagpapawalang-bisa na nasa papel lamang.

Hakbang 1: Ano ang ibinabalik ng bawat pagsusuri at gaano katagal itong nananatiling magagamit

Ang CRL ay inilalathala bilang isang pinirmahang bagay na sumasaklaw sa bawat sertipikong pinawalang-bisa ng isang tagapaglabas, kaya hinihingi ito ng tagapagpatunay nang isang beses at muling ginagamit hanggang lumipas ang nextUpdate ng listahan. Ang tugon ng OCSP ay mas makitid: sumasagot ito para sa eksaktong isang sertipiko at may dalang thisUpdate, producedAt at karaniwan ding nextUpdate. Ang pagkakaibang iyon ang nagtuturo sa lahat ng iba pa. Ang naka-cache na CRL ay tahimik na tumatanda, dahil pinoproseso pa rin ang file at binibigyang-katibayan pa rin ang pirma nito, samantalang ang nag-expire na tugon ng OCSP ay malinaw na walang halaga sa sandaling basahin mo ang mga timestamp nito.

Kaya ang cache ang unang bagay na dapat itakda: aling bahagi ang humahawak ng kopya, at anong kisame ang sinusunod ng kopyang iyon. Sa isang gateway ang kisame ay dapat na nextUpdate na binawasan ng safety margin, hindi kailanman ang anumang iminumungkahi ng header ng cache ng HTTP nang nagkataon. openssl crl -in issuer.crl -noout -lastupdate -nextupdate naglilimbag ng dalawang petsa, at ang listahang ang nextUpdate ay nasa nakaraan na ay dapat ituring na nawawala at hindi lamang luma.

Hakbang 2: Saan itinuturo ng sertipiko ang kliyente

Ang leaf certificate ay karaniwang may dalang dalawang pahiwatig: isang extension ng punto ng pamamahagi ng CRL at isang entry ng pag-access sa impormasyon ng awtoridad para sa OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints ang naglilimbag ng una, at ang pangalawa ay nasa ilalim ng seksyong AIA ng openssl x509 -in client.pem -noout -text. Ang alinman sa mga extension ay isang panturo, hindi isang tungkulin. Ang kliyenteng hindi kailanman nagpapatupad ng pagsusuri ng pagpapawalang-bisa ay makakakonekta nang maayos sa isang sertipikong ang mga extension ay nagbabanggit ng isang tagatugon na patay na nang isang taon.

Ang mga punto ng pamamahagi ay madalas na nagbabanggit ng panloob na host na nare-resolve lamang sa loob ng isang segment ng network, at ang ilang lumang kliyente ay tahasang tumatanggi sa mga URL na ldap. Subukan ang maabot mula sa host na nagtatapos sa tunnel, hindi mula sa sarili mong laptop, dahil iyon ang tanging pananaw na talagang mahalaga ang pagkabigo.

Hakbang 3: Pumili ng fail-closed o fail-open bago ang pagkawala ng serbisyo

Ang hindi maabot na tagatugon o ang nag-expire na listahan ay nagpipilit ng desisyon: tanggihan ang koneksiyon, o tanggapin ito at itala ang agwat. Ginagawang malinaw ng verify subcommand ng OpenSSL ang mahigpit na pagpili, dahil ang pagdaragdag ng -crl_check ay ginagawang unable to get certificate CRL ang isang CRL na hindi magagamit at nabigong pagpapatunay. Ang soft-fail sa karamihan ng stack ay hindi talaga flag, ito ang kawalan ng pagsusuri, at iyon ang dahilan kung bakit naipapadala ito nang aksidente.

Para makita kung anong pag-uugali talaga ang mayroon ang isang kliyente, alisin ang tagatugon at kumonekta muli. Kung umaangat pa rin ang tunnel, hanapin ang log line na nagtala ng nilaktawang pagsusuri, pagkatapos ay itanong kung may magbabasa ba ng linyang iyon habang may insidente. Ang parehong vendor ay maaaring magkaiba ayon sa protocol: ang kliyenteng IKEv2 at ang kliyenteng OpenVPN sa isang makina ay nagbabasa ng magkaibang setting ng configuration.

Hakbang 4: Patunayan na tumatakbo ang pagsusuri sa lugar kung saan tinatanggap ang trapiko

Hanapin ang prosesong nagtatapos o nagpapahintulot ng koneksiyon, pagkatapos ay itanong dito ang configuration line na nagpapagana ng pagsusuri ng pagpapawalang-bisa. Ang gateway na nagpapatunay ng chain ngunit hindi kailanman nagtatanong tungkol sa pagpapawalang-bisa ay nagpapatupad ng patakarang iba sa nasa dokumentasyon mo, at walang screenshot ng chain ng sertipiko ang nagpapatunay ng kabaligtaran. Isinusulat ng OpenVPN ang opsyong ito bilang crl-verify; inilalagay ng strongSwan ang paghahanap ng CRL at OCSP sa ilalim ng configuration ng CA, kung saan itinatakda ang crl_uris o ocsp_uris. Kung hindi mo mapupunto ang alinman sa dalawa, ipagpalagay na wala ang pagsusuri.

Ang tugon ng OCSP ay may bisa lamang kapag pinirmahan ito ng naglalabas na CA, o kapag pinirmahan ito ng tagatugon na may pinagkatiwalaang pinahabang paggamit ng susi na OCSPSigning ng CA na iyon, kaya ang sagot mula sa walang kaugnayang serbisyo ay walang pinatutunayan. Kung ikaw mismo ang nagpapatakbo ng tagatugon, subaybayan ito bilang matigas na dependency, dahil ang isang patay na serbisyo ay agad na nagiging pagkawala ng serbisyo para sa bawat kliyenteng fail-closed.

Hakbang 5: Sadyang pawalang-bisa ang isang sertipiko

Kumuha ng test na sertipiko, pawalang-bisa ito sa parehong channel na ginagamit ng produksiyon, at tanungin nang direkta ang tagatugon. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text ay dapat mag-ulat ng Cert Status: revoked kasama ang oras ng pagpapawalang-bisa, at ang sagot na good ay nangangahulugang hindi naabot ng iyong pagpapawalang-bisa ang tagatugong tinatanong ng iyong mga kliyente. Pagkatapos ay patakbuhin ang openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem upang makita ang parehong desisyon sa ruta ng listahan. Basahin ang string ng dahilan sa halip na ang exit code, dahil ang pagtanggi dahil sa pagpapawalang-bisa at ang error sa chain ay parehong nauuwi sa kabiguan.

Ang hakbang na talagang mahalaga ay ang huli: kumonekta muli gamit ang lumang profile laban sa aktwal na punto ng pagpapatupad at kumpirmahin na ang pagtanggi ay nagmumula sa pagpapawalang-bisa. Pagkatapos ay kumonekta muli gamit ang bago at valid na sertipiko upang patunayang hindi mo lamang sinira ang tagapakinig. Ang pagbura ng profile sa kliyente ay walang pinatutunayan tungkol sa desisyon ng server, at gayundin ang matagumpay na pagpapatakbo ng openssl verify sa makinang hindi kailanman nagtatapos ng tunnel. Tinutukoy ng RFC 6960 kung ano ang nilalaman ng isang tugon ng OCSP na naaayon, kasama ang mga halaga ng katayuan na binabasa ng pagsubok na ito.