OCSP proti CRL: kako vsako preverjanje preklica v resnici deluje

Eno od teh dveh preverjanj preklica vrne podpisan odgovor o enem samem potrdilu, drugo pa vrne podpisan seznam, ki ga prenesete v celoti. Oba naj bi preverjevalcu povedala, ali je poverilnica še zaupanja vredna, in oba spodletita na načine, ki si nista prav nič podobna. Spodnji vrstni red sledi temu, s čimer se upravljavec v produkciji res sreča, od bajtov na žici do prehoda, ki zavrne povezavo. Prav preskočitev koraka privede do tega, da namestitev ostane s politiko preklica, ki obstaja le na papirju.

Korak 1: Kaj vsako preverjanje vrne in kako dolgo ostane uporabno

CRL se objavi kot en podpisan objekt, ki zajema vsako potrdilo, ki ga je izdajatelj preklical, zato ga preverjevalec pridobi enkrat in ga znova uporabi, dokler ne mine nextUpdate seznama. Odziv OCSP je ožji: odgovori natanko za eno potrdilo in nosi thisUpdate, producedAt ter običajno tudi nextUpdate. Ta razlika določa vse ostalo. Predpomnjeni CRL tiho zastara, ker se datoteka še vedno razčlenjuje in njen podpis še vedno preverja, medtem ko je potekel odziv OCSP očitno brez vrednosti v trenutku, ko preberete njegove časovne žige.

Zato je predpomnjenje prva stvar, ki jo je treba določiti: katera komponenta hrani kopijo in kateri zgornji meji ta kopija sledi. Na prehodu bi morala biti meja nextUpdate minus varnostna rezerva, nikoli to, kar slučajno predlaga glava predpomnilnika HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate izpiše oba datuma in seznam, katerega nextUpdate je že v preteklosti, je treba obravnavati kot manjkajoč in ne le kot star.

Korak 2: Kam potrdilo usmeri odjemalca

Listno potrdilo običajno nosi dva namiga: razširitev točke distribucije CRL in vnos dostopa do informacij organa za OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints izpiše prvega, drugi pa je v razdelku AIA izpisa openssl x509 -in client.pem -noout -text. Vsaka od razširitev je kazalka, ne obveznost. Odjemalec, ki nikoli ne izvede preverjanja preklica, se bo povsem dobro povezal s potrdilom, katerega razširitve navajajo odzivnika, ki je mrtev že leto.

Točke distribucije pogosto navajajo notranji gostitelj, ki se razreši le znotraj enega omrežnega segmenta, nekateri starejši odjemalci pa naslove URL ldap preprosto zavrnejo. Dosegljivost preizkusite z gostitelja, ki zaključi tunel, ne z lastnega prenosnika, ker je to edino stališče, katerega napaka v resnici šteje.

Korak 3: Izberite fail-closed ali fail-open pred izpadom

Nedosegljiv odzivnik ali potekel seznam prisili v odločitev: povezavo zavrniti ali jo sprejeti in vrzel zabeležiti. Podukaz verify v OpenSSL naredi strogo izbiro izrecno, ker dodajanje -crl_check spremeni nedosegljiv CRL v unable to get certificate CRL in neuspešno preverjanje. Soft-fail v večini skladov sploh ni zastavica, temveč odsotnost preverjanja, in prav zato prispe v produkcijo po nesreči.

Če želite videti, kakšno vedenje odjemalec v resnici ima, odstranite odzivnik in se znova povežite. Če se tunel vseeno dvigne, poiščite vrstico dnevnika, ki je zabeležila preskočeno preverjanje, in se nato vprašajte, ali bi kdo to vrstico bral med incidentom. Isti ponudnik se lahko razlikuje po protokolu: odjemalec IKEv2 in odjemalec OpenVPN na istem stroju bereta nepovezane konfiguracijske parametre.

Korak 4: Dokažite, da preverjanje teče tam, kjer je promet sprejet

Poiščite postopek, ki zaključi ali avtorizira povezavo, in ga vprašajte po konfiguracijski vrstici, ki omogoči preverjanje preklica. Prehod, ki potrdi verigo, a nikoli ne vpraša o preklicu, uveljavlja drugačno politiko od tiste v vaši dokumentaciji, in noben posnetek zaslona verige potrdil ne dokaže nasprotnega. OpenVPN to možnost zapiše kot crl-verify; strongSwan hrani iskanja CRL in OCSP v konfiguraciji CA, kjer se nastavita crl_uris ali ocsp_uris. Če ne morete pokazati na nobeno od obeh, predpostavite, da preverjanja ni.

Odziv OCSP velja le, ko ga podpiše izdajateljica CA, ali ko ga podpiše odzivnik z razširjeno uporabo ključa OCSPSigning, ki mu jo je podelila ta CA, zato odziv nepovezane storitve ne dokaže ničesar. Če odzivnik upravljate sami, ga spremljajte kot trdo odvisnost, ker ena mrtva storitev hkrati postane izpad za vsakega odjemalca fail-closed.

Korak 5: Namerno prekličite eno potrdilo

Vzemite preskusno potrdilo, prekličite ga po istem kanalu, ki ga uporablja produkcija, in vprašajte odzivnik neposredno. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text bi moral poročati Cert Status: revoked skupaj s časom preklica, odgovor good pa pomeni, da vaš preklic ni dosegel odzivnika, ki ga sprašujejo vaši odjemalci. Nato zaženite openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, da vidite isto odločitev po poti seznama. Berite niz razloga namesto izhodne kode, ker zavrnitev zaradi preklica in napaka v verigi oba končata z neuspehom.

Korak, ki v resnici šteje, je zadnji: znova se povežite s starim profilom proti resnični točki uveljavljanja in potrdite, da zavrnitev izhaja iz preklica. Nato se znova povežite s svežim, veljavnim potrdilom, da dokažete, da niste le pokvarili poslušalca. Brisanje profila na odjemalcu ne dokaže ničesar o odločitvi strežnika, prav tako pa tudi ne uspešen zagon openssl verify na stroju, ki nikoli ne zaključi tunela. RFC 6960 določa, kaj vsebuje skladen odziv OCSP, vključno z vrednostmi stanja, ki jih bere ta preskus.