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 potpisani popis koji preuzimate cijeli. Obje trebaju reći verifikatoru je li vjerodajnica još uvijek pouzdana, i obje padaju na načine koji nimalo ne sliče jedna na drugu. Redoslijed u nastavku prati ono na što operater u proizvodnji stvarno nailazi, počevši od bajtova na žici i završavajući gatewayom koji odbija vezu. Preskakanje koraka način je na koji implementacija završi s politikom opoziva koja postoji samo na papiru.

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

CRL se objavljuje kao jedan potpisani objekt koji pokriva svaki certifikat koji je izdavatelj opozvao, pa ga verifikator preuzme jednom i ponovno koristi dok ne prođe nextUpdate popisa. OCSP odgovor je uži: odgovara točno za jedan certifikat i nosi thisUpdate, producedAt i obično i nextUpdate. Ta razlika pokreće sve ostalo. Predmemorirani CRL tiho zastarijeva, jer se datoteka još uvijek parsira i njezin se potpis još uvijek provjerava, dok je istekao OCSP odgovor očito bezvrijedan u trenutku kada pročitate njegove vremenske oznake.

Predmemoriranje je stoga prvo što treba utvrditi: koja komponenta drži kopiju i kojem gornjem limitu ta kopija podliježe. Na gatewayu gornji limit treba biti nextUpdate minus sigurnosna margina, nikada ono što slučajno predloži HTTP zaglavlje predmemorije. openssl crl -in issuer.crl -noout -lastupdate -nextupdate ispisuje oba datuma, a popis čiji je nextUpdate već u prošlosti mora se tretirati kao da nedostaje, a ne samo kao star.

Korak 2: Kamo certifikat usmjerava klijenta

Listovni certifikat obično nosi dva nagovještaja: ekstenziju točke distribucije CRL-a i unos pristupa informacijama tijela 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 pokazivač je, ne obveza. Klijent koji nikada ne implementira provjeru opoziva povezat će se sasvim dobro s certifikatom čije ekstenzije imenuju responder koji je mrtav već godinu.

Točke distribucije često imenuju interni host koji se razrješava samo unutar jednog mrežnog segmenta, a neki stariji klijenti uopće odbijaju ldap URL-ove. Testirajte dostupnost s hosta koji terminira tunel, ne sa svog prijenosnika, jer je to jedino gledište čiji kvar zaista ima značenje.

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

Nedostupan responder ili istekao popis prisiljava na odluku: odbiti vezu ili je prihvatiti i zabilježiti prazninu. OpenSSL-ova podnaredba verify čini strog izbor eksplicitnim, jer dodavanje -crl_check pretvara nedostupan CRL u unable to get certificate CRL i neuspjelu provjeru. Soft-fail u većini stackova uopće nije zastavica, to je odsutnost provjere, i upravo zato stiže slučajno.

Da vidite kakvo ponašanje klijent zaista ima, uklonite responder i ponovno se povežite. Ako se tunel ipak podigne, pronađite retku dnevnika koja je zabilježila preskočenu provjeru, pa pitajte bi li itko tu retku čitao tijekom 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 promet prihvaća

Pronađite proces koji terminira ili autorizira vezu, pa ga pitajte za konfiguracijsku retku koja omogućuje 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 zaslona 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 izdavatelj 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 ovisnost, 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 proizvodnja i pitajte responder izravno. 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 popisa. Čitajte niz razloga umjesto izlaznog koda, jer odbijanje zbog opoziva i pogreška u lancu oba završavaju neuspjehom.

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