OCSP nasuprot CRL-u: kako svaka provjera opoziva zapravo radi

Jedna od ove dvije provjere opoziva vraća potpisan odgovor o jednom certifikatu, a druga vraća potpisanu listu koju preuzimate cijelu. Obje treba da kažu verifikatoru da li je neka vjerodajnica još uvijek pouzdana, i obje padaju na načine koji nimalo ne liče jedna na drugu. Redoslijed ispod prati ono na šta operater stvarno nailazi u produkciji, počevši od bajtova na žici i završavajući gatewayom koji odbija konekciju. Preskakanje koraka je način na koji implementacija završi s politikom opoziva koja postoji samo na papiru.

Korak 1: Šta svaka provjera vraća i koliko dugo ostaje upotrebljiva

CRL se objavljuje kao jedan potpisan objekat koji pokriva svaki certifikat koji je izdavalac opozvao, pa ga verifikator preuzme jednom i koristi ponovo dok ne prođe nextUpdate liste. OCSP odgovor je uži: odgovara tačno za jedan certifikat i nosi thisUpdate, producedAt i obično i nextUpdate. Ta razlika pokreće sve ostalo. Keširani CRL tiho zastarijeva, jer se datoteka još uvijek parsira i njen potpis još uvijek provjerava, dok je istekao OCSP odgovor očigledno bezvrijedan u trenutku kada pročitate njegove vremenske oznake.

Keširanje je zato prvo što treba utvrditi: koja komponenta drži kopiju i kojem plafonu ta kopija podliježe. Na gatewayu plafon treba da bude nextUpdate minus sigurnosna margina, nikada ono što slučajno predloži HTTP keš zaglavlje. openssl crl -in issuer.crl -noout -lastupdate -nextupdate ispisuje oba datuma, a lista čiji je nextUpdate već u prošlosti mora se tretirati kao da nedostaje, a ne samo kao stara.

Korak 2: Kuda certifikat usmjerava klijenta

Listovni certifikat obično nosi dva nagovještaja: ekstenziju tačke distribucije CRL-a i unos pristupa informacijama autoriteta za OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints ispisuje prvo, a drugo se nalazi pod odjeljkom AIA izlaza openssl x509 -in client.pem -noout -text. Svaka od tih ekstenzija je pokazivač, ne obaveza. Klijent koji nikada ne implementira provjeru opoziva povezat će se sasvim dobro sa certifikatom čije ekstenzije imenuju responder koji je mrtav već godinu.

Tačke distribucije često imenuju interni host koji se razrješava samo unutar jednog mrežnog segmenta, a neki stariji klijenti uopšte odbijaju ldap URL-ove. Testirajte dostupnost sa hosta koji terminira tunel, ne sa svog laptopa, jer je to jedina tačka gledišta čiji otkaz zaista ima značenje.

Korak 3: Odaberite fail-closed ili fail-open prije prekida

Nedostupan responder ili istekla lista prisiljava na odluku: odbiti konekciju ili je prihvatiti i zabilježiti prazninu. OpenSSL-ova podkomanda verify čini strog izbor eksplicitnim, jer dodavanje -crl_check pretvara nedostupan CRL u unable to get certificate CRL i neuspjelu verifikaciju. Soft-fail u većini stackova uopšte nije zastavica, to je odsustvo provjere, i upravo zato stiže slučajno.

Da vidite kakvo ponašanje klijent zaista ima, uklonite responder i ponovo se povežite. Ako se tunel ipak podigne, pronađite log liniju koja je zabilježila preskočenu provjeru, pa pitajte bi li iko tu liniju čitao tokom incidenta. Isti proizvođač može se razlikovati po protokolu: IKEv2 klijent i OpenVPN klijent na istom stroju čitaju nepovezane konfiguracijske parametre.

Korak 4: Dokažite da provjera radi tamo gdje se saobraćaj prihvata

Pronađite proces koji terminira ili autorizira konekciju, pa ga pitajte za konfiguracijsku liniju koja omogućava provjeru opoziva. Gateway koji validira lanac ali nikada ne pita za opoziv primjenjuje drugačiju politiku od one u vašoj dokumentaciji, i nijedna snimka ekrana lanca certifikata ne dokazuje suprotno. OpenVPN tu opciju piše kao crl-verify; strongSwan drži CRL i OCSP pretrage pod CA konfiguracijom, gdje se postavljaju crl_uris ili ocsp_uris. Ako ne možete pokazati ni na jedno, pretpostavite da provjere nema.

OCSP odgovor vrijedi samo kada ga je potpisao izdavalac CA, ili kada ga je potpisao responder koji nosi proširenu upotrebu ključa OCSPSigning koju je taj CA delegirao, pa odgovor nepovezane usluge ništa ne dokazuje. Ako sami vodite responder, nadzirite ga kao tvrdu zavisnost, jer jedna mrtva usluga odjednom postaje prekid za svakog fail-closed klijenta.

Korak 5: Namjerno opozovite jedan certifikat

Uzmite testni certifikat, opozovite ga kroz isti kanal koji koristi produkcija i pitajte responder direktno. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text treba prijaviti Cert Status: revoked zajedno s vremenom opoziva, a odgovor good znači da vaš opoziv nije stigao do respondera kojeg vaši klijenti pitaju. Zatim pokrenite openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem da vidite istu odluku kroz putanju liste. Čitajte niz razloga umjesto izlaznog koda, jer odbijanje zbog opoziva i greška u lancu oba završavaju neuspjehom.

Korak koji zaista ima značenje je posljednji: povežite se ponovo sa starim profilom na stvarnoj tački primjene i potvrdite da odbijanje dolazi od opoziva. Zatim se ponovo povežite sa svježim, važećim certifikatom da dokažete da niste samo pokvarili listener. Brisanje profila na klijentu ništa ne dokazuje o odluci servera, kao ni uspješno pokretanje openssl verify na stroju koji nikada ne terminira tunel. RFC 6960 definiše šta sadrži usklađen OCSP odgovor, uključujući vrijednosti statusa koje ovaj test čita.