OCSP verzus CRL: ako každá kontrola odvolania skutočne funguje

Jedna z týchto dvoch kontrol odvolania vracia podpísanú odpoveď o jedinom certifikáte a druhá vracia podpísaný zoznam, ktorý stiahnete celý. Obe majú overovateľovi povedať, či je poverenie stále dôveryhodné, a obe zlyhávajú spôsobmi, ktoré si vôbec nie sú podobné. Poradie nižšie sleduje to, s čím sa operátor v produkcii skutočne stretne, od bajtov na drôte až po bránu, ktorá odmietne spojenie. Práve vynechanie kroku vedie k tomu, že nasadenie skončí so zásadou odvolania, ktorá existuje len na papieri.

Krok 1: Čo každá kontrola vracia a ako dlho zostáva použiteľná

CRL sa zverejňuje ako jeden podpísaný objekt pokrývajúci každý certifikát, ktorý vydavateľ odvolal, takže si ho overovateľ stiahne raz a znova použije, kým neuplynie nextUpdate zoznamu. Odpoveď OCSP je užšia: odpovedá presne na jeden certifikát a nesie thisUpdate, producedAt a zvyčajne aj nextUpdate. Práve tento rozdiel riadi všetko ostatné. Kešovaná CRL ticho starne, pretože súbor sa stále parsuje a jeho podpis sa stále overuje, kým prešlá odpoveď OCSP je zjavne bezcenná vo chvíli, keď si prečítate jej časové pečiatky.

Kešovanie je preto prvá vec, ktorú treba určiť: ktorá komponenta drží kópiu a akému stropu táto kópia podlieha. Na bráne má byť stropom nextUpdate mínus bezpečnostná rezerva, nikdy to, čo náhodou navrhne hlavička HTTP keše. openssl crl -in issuer.crl -noout -lastupdate -nextupdate vypíše oba dátumy a zoznam, ktorého nextUpdate je už v minulosti, treba považovať za chýbajúci, a nie len za starý.

Krok 2: Kam certifikát nasmeruje klienta

Listový certifikát zvyčajne nesie dve nápovedy: rozšírenie distribučného bodu CRL a záznam prístupu k informáciám autority pre OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints vypíše prvú a druhá sa nachádza v sekcii AIA výstupu openssl x509 -in client.pem -noout -text. Obe rozšírenia sú ukazovateľ, nie povinnosť. Klient, ktorý nikdy neimplementuje kontrolu odvolania, sa úplne bez problémov pripojí k certifikátu, ktorého rozšírenia menujú respondera mŕtveho už rok.

Distribučné body často menujú interný hostiteľ, ktorý sa prekladá len v jednom sieťovom segmente, a niektorí starší klienti ldap URL rovno odmietajú. Testujte dostupnosť z hostiteľa, ktorý ukončuje tunel, nie zo svojho notebooku, pretože to je jediné stanovisko, ktorého zlyhanie skutočne záleží.

Krok 3: Vyberte fail-closed alebo fail-open ešte pred výpadkom

Nedostupný responder alebo prešlý zoznam vynúti rozhodnutie: spojenie odmietnuť, alebo ho prijať a medzeru zaznamenať. Podpríkaz verify v OpenSSL robí striktnú voľbu explicitnou, pretože pridanie -crl_check premení nedostupnú CRL na unable to get certificate CRL a neúspešné overenie. Soft-fail vo väčšine stackov vôbec nie je prepínač, je to neprítomnosť kontroly, a práve preto sa dostane do prevádzky omylom.

Ak chcete zistiť, aké správanie klient skutočne má, odoberte respondera a pripojte sa znova. Ak tunel stále naskočí, nájdite riadok logu, ktorý zaznamenal preskočenú kontrolu, a potom sa spýtajte, či by ten riadok niekto počas incidentu čítal. Ten istý dodávateľ sa môže líšiť podľa protokolu: klient IKEv2 a klient OpenVPN na jednom stroji čítajú nesúvisiace konfiguračné parametre.

Krok 4: Dokážte, že kontrola beží tam, kde je prevádzka prijímaná

Nájdite proces, ktorý spojenie ukončuje alebo autorizuje, a spýtajte sa ho na konfiguračný riadok, ktorý povoľuje kontrolu odvolania. Brána, ktorá validuje reťazec, ale nikdy sa nepýta na odvolanie, uplatňuje inú zásadu než tá vo vašej dokumentácii, a žiadny snímok obrazovky reťazca certifikátov nedokazuje opak. OpenVPN túto voľbu píše ako crl-verify; strongSwan drží vyhľadávanie CRL a OCSP v konfigurácii CA, kde sa nastavujú crl_uris alebo ocsp_uris. Ak nemôžete ukázať ani na jedno, predpokladajte, že kontrola chýba.

Odpoveď OCSP platí len vtedy, keď ju podpísala vydávajúca CA, alebo keď ju podpísal responder s rozšíreným použitím kľúča OCSPSigning delegovaným touto CA, takže odpoveď nesúvisiacej služby nič nedokazuje. Ak respondera prevádzkujete sami, monitorujte ho ako tvrdú závislosť, pretože jediná mŕtva služba sa naraz stane výpadkom pre každého fail-closed klienta.

Krok 5: Zámerne odvolajte jeden certifikát

Vezmite testovací certifikát, odvolajte ho tým istým kanálom, ktorý používa produkcia, a spýtajte sa respondera priamo. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text by mal nahlásiť Cert Status: revoked spolu s časom odvolania a odpoveď good znamená, že vaše odvolanie nedorazilo k responderovi, ktorého sa vaši klienti pýtajú. Potom spustite openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, aby ste rovnaké rozhodnutie videli cestou zoznamu. Čítajte reťazec dôvodu namiesto návratového kódu, pretože odmietnutie pre odvolanie aj chyba reťazca končia zlyhaním.

Krok, na ktorom skutočne záleží, je posledný: pripojte sa znova so starým profilom proti skutočnému miestu vynútenia a potvrďte, že odmietnutie pochádza z odvolania. Potom sa pripojte znova s čerstvým platným certifikátom, aby ste dokázali, že ste len nepokazili listener. Vymazanie profilu na klientovi nič nedokazuje o rozhodnutí servera, a rovnako ani úspešné spustenie openssl verify na stroji, ktorý nikdy neukončuje tunel. RFC 6960 definuje, čo obsahuje vyhovujúca odpoveď OCSP, vrátane stavových hodnôt, ktoré tento test číta.