OCSP versus CRL: jak každá kontrola odvolání skutečně funguje

Jedna z těchto dvou kontrol odvolání vrací podepsanou odpověď o jediném certifikátu a druhá vrací podepsaný seznam, který stáhnete celý. Obě mají ověřovateli sdělit, zda je pověření stále důvěryhodné, a obě selhávají způsoby, které si nejsou vůbec podobné. Pořadí níže sleduje to, s čím se operátor v produkci skutečně setká, od bajtů na drátě až po bránu, která odmítne spojení. Právě vynechání kroku vede k tomu, že nasazení skončí se zásadou odvolání, která existuje jen na papíře.

Krok 1: Co každá kontrola vrací a jak dlouho zůstává použitelná

CRL se zveřejňuje jako jeden podepsaný objekt pokrývající každý certifikát, který vydavatel odvolal, takže si jej ověřovatel stáhne jednou a znovu použije, dokud neuplyne nextUpdate seznamu. Odpověď OCSP je užší: odpovídá přesně na jeden certifikát a nese thisUpdate, producedAt a obvykle i nextUpdate. Právě tento rozdíl řídí všechno ostatní. Kešovaná CRL tiše zastará, protože soubor se stále parsuje a jeho podpis se stále ověřuje, kdežto prošlá odpověď OCSP je zjevně bezcenná ve chvíli, kdy si přečtete její časová razítka.

Kešování je proto první věc, kterou je třeba určit: která komponenta drží kopii a jakému stropu tato kopie podléhá. Na bráně má být stropem nextUpdate minus bezpečnostní rezerva, nikdy to, co náhodou navrhne hlavička HTTP keše. openssl crl -in issuer.crl -noout -lastupdate -nextupdate vypíše obě data a seznam, jehož nextUpdate je již v minulosti, je třeba považovat za chybějící, a ne jen za starý.

Krok 2: Kam certifikát nasměruje klienta

Listový certifikát obvykle nese dvě nápovědy: rozšíření distribučního bodu CRL a záznam přístupu k informacím autority pro OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints vypíše první a druhé se nachází v sekci AIA výstupu openssl x509 -in client.pem -noout -text. Obě rozšíření jsou ukazatel, nikoli povinnost. Klient, který nikdy neimplementuje kontrolu odvolání, se zcela bez problémů připojí k certifikátu, jehož rozšíření jmenují responder, který je mrtvý už rok.

Distribuční body často jmenují interní hostitel, který se překládá jen v jednom síťovém segmentu, a někteří starší klienti ldap adresy URL rovnou odmítají. Testujte dostupnost z hostitele, který tunel ukončuje, ne ze svého notebooku, protože to je jediné stanovisko, jehož selhání skutečně záleží.

Krok 3: Vyberte fail-closed nebo fail-open ještě před výpadkem

Nedostupný responder nebo prošlý seznam vynutí rozhodnutí: spojení odmítnout, nebo je přijmout a mezeru zaznamenat. Podpříkaz verify v OpenSSL činí striktní volbu explicitní, protože přidání -crl_check promění nedostupnou CRL v unable to get certificate CRL a neúspěšné ověření. Soft-fail ve většině stacků vůbec není přepínač, je to nepřítomnost kontroly, a právě proto se dostane do provozu omylem.

Chcete-li zjistit, jaké chování klient skutečně má, odeberte respondera a připojte se znovu. Pokud tunel stále naskočí, najděte řádek logu, který zaznamenal přeskočenou kontrolu, a pak se zeptejte, zda by ten řádek někdo během incidentu četl. Stejný dodavatel se může lišit podle protokolu: klient IKEv2 a klient OpenVPN na jednom stroji čtou nesouvisející konfigurační parametry.

Krok 4: Dokažte, že kontrola běží tam, kde je provoz přijímán

Najděte proces, který spojení ukončuje nebo autorizuje, a zeptejte se ho na konfigurační řádek, který povoluje kontrolu odvolání. Brána, která validuje řetězec, ale nikdy se na odvolání neptá, uplatňuje jinou zásadu než ta ve vaší dokumentaci, a žádný snímek obrazovky řetězce certifikátů nedokazuje opak. OpenVPN tuto volbu píše jako crl-verify; strongSwan drží vyhledávání CRL i OCSP v konfiguraci CA, kde se nastavují crl_uris nebo ocsp_uris. Pokud nemůžete ukázat ani na jedno, předpokládejte, že kontrola chybí.

Odpověď OCSP platí jen tehdy, když ji podepsala vydávající CA, nebo když ji podepsal responder s rozšířeným použitím klíče OCSPSigning delegovaným touto CA, takže odpověď nesouvisející služby nic nedokazuje. Pokud responder provozujete sami, monitorujte jej jako tvrdou závislost, protože jediná mrtvá služba se rázem stane výpadkem pro každého fail-closed klienta.

Krok 5: Záměrně odvolejte jeden certifikát

Vezměte testovací certifikát, odvolejte jej stejným kanálem, který používá produkce, a zeptejte se respondera přímo. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text by měl hlásit Cert Status: revoked spolu s časem odvolání a odpověď good znamená, že vaše odvolání nedorazilo k responderu, který vaši klienti dotazují. Poté spusťte openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, abyste stejné rozhodnutí viděli cestou seznamu. Čtěte řetězec důvodu místo návratového kódu, protože odmítnutí kvůli odvolání i chyba řetězce končí selháním.

Krok, na kterém skutečně záleží, je poslední: připojte se znovu se starým profilem proti skutečnému místu vynucení a potvrďte, že odmítnutí pochází z odvolání. Poté se připojte znovu s čerstvým platným certifikátem, abyste dokázali, že jste jen nerozbili listener. Smazání profilu na klientovi nic nedokazuje o rozhodnutí serveru, a stejně tak úspěšné spuštění openssl verify na stroji, který nikdy neukončuje tunel. RFC 6960 definuje, co odpovídající odpověď OCSP obsahuje, včetně stavových hodnot, které tento test čte.