OCSP kontra en CRL: hvordan hver tilbagekaldelseskontrol egentlig virker

En af disse to tilbagekaldelseskontroller returnerer et signeret svar om ét enkelt certifikat, og den anden returnerer en signeret liste, som du downloader i sin helhed. Begge skal fortælle en verifier, om en legitimationsoplysning stadig er betroet, og begge fejler på måder, der slet ikke ligner hinanden. Rækkefølgen nedenfor følger det, en operatør faktisk møder i produktion, begyndende med byte på tråden og sluttende med en gateway, der afviser en forbindelse. At springe et trin over er måden, hvorpå en udrulning ender med en tilbagekaldelsespolitik, der kun findes på papir.

Trin 1: Hvad hver kontrol giver tilbage, og hvor længe den forbliver brugbar

En CRL offentliggøres som ét signeret objekt, der dækker hvert certifikat, en udsteder har tilbagekaldt, så en verifier henter den én gang og genbruger den, indtil listens nextUpdate er passeret. Et OCSP-svar er smallere: det svarer på præcis ét certifikat og bærer thisUpdate, producedAt og som regel også nextUpdate. Den forskel styrer alt andet. En cachet CRL bliver stille forældet, fordi filen stadig kan parses, og dens signatur stadig verificeres, mens et udløbet OCSP-svar er åbenlyst værdiløst i det øjeblik, du læser dets tidsstempler.

Caching er derfor det første, der skal fastlægges: hvilken komponent holder kopien, og hvilket loft den kopi adlyder. På en gateway bør loftet være nextUpdate minus en sikkerhedsmargin, aldrig hvad en HTTP-cacheheader tilfældigvis foreslår. openssl crl -in issuer.crl -noout -lastupdate -nextupdate udskriver begge datoer, og en liste, hvis nextUpdate allerede er i fortiden, skal behandles som manglende og ikke blot som gammel.

Trin 2: Hvor certifikatet peger klienten hen

Bladcertifikatet bærer normalt to hints: en CRL-distributionspunktudvidelse og en indgang for autoritetsinformationsadgang til OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints udskriver den første, og den anden ligger under AIA-afsnittet i openssl x509 -in client.pem -noout -text. Hver af udvidelserne er en pegepind, ikke en forpligtelse. En klient, der aldrig implementerer tilbagekaldelseskontrol, vil forbinde ganske fint til et certifikat, hvis udvidelser navngiver en responder, der har været død i et år.

Distributionspunkter navngiver ofte en intern vært, der kun opløses inden for ét netværkssegment, og nogle ældre klienter afviser ldap-URL'er helt. Test rækkevidde fra den vært, der terminerer tunnelen, ikke fra din egen laptop, fordi det er det eneste synspunkt, hvis fejl faktisk betyder noget.

Trin 3: Vælg fail-closed eller fail-open før afbrydelsen

En utilgængelig responder eller en udløbet liste tvinger en beslutning: afvis forbindelsen, eller accepter den og registrer hullet. OpenSSLs verify-underkommando gør det strenge valg eksplicit, fordi tilføjelse af -crl_check gør en utilgængelig CRL til unable to get certificate CRL og en mislykket verifikation. Soft-fail i de fleste stakke er slet ikke et flag, det er fraværet af kontrollen, og det er præcis derfor, den kommer med ved en fejl.

For at se, hvilken opførsel en klient egentlig har, fjern responder-en og genopret forbindelsen. Hvis tunnelen stadig kommer op, find den loglinje, der registrerede den springede kontrol, og spørg så, om nogen ville læse den linje under en hændelse. Den samme leverandør kan variere fra protokol til protokol, med en IKEv2-klient og en OpenVPN-klient på én maskine, der læser ubeslægtede konfigurationsknapper.

Trin 4: Bevis, at kontrollen kører, hvor trafik lukkes ind

Find den proces, der terminerer eller autoriserer forbindelsen, og spørg den om den konfigurationslinje, der aktiverer tilbagekaldelseskontrol. En gateway, der validerer kæden, men aldrig spørger til tilbagekaldelse, håndhæver en anden politik end den i din dokumentation, og intet skærmbillede af en certifikatkæde beviser det modsatte. OpenVPN skriver valgmuligheden som crl-verify; strongSwan holder CRL- og OCSP-opslag under CA-konfigurationen, hvor crl_uris eller ocsp_uris sættes. Hvis du ikke kan pege på nogen af dem, antag at kontrollen mangler.

Et OCSP-svar tæller kun, når den udstedende CA har signeret det, eller når en responder med OCSPSigning-udvidelsen til udvidet nøglebrug, delegeret af den CA, har signeret det, så et svar fra en uvedkommende tjeneste beviser intet. Hvis du selv kører responder-en, overvåg den som en hård afhængighed, fordi én død tjeneste på én gang bliver et udfald for hver fail-closed-klient.

Trin 5: Tilbagekald ét certifikat med vilje

Tag et testcertifikat, tilbagekald det gennem samme kanal, som produktionen bruger, og spørg responder-en direkte. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text bør rapportere Cert Status: revoked sammen med et tilbagekaldelsestidspunkt, og et good-svar betyder, at din tilbagekaldelse ikke nåede den responder, dine klienter spørger. Kør derefter openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem for at se samme beslutning gennem listestien. Læs årsagsstrengen i stedet for exitkoden, fordi en tilbagekaldelsesafvisning og en kædefejl begge ender i fejl.

Det trin, der faktisk betyder noget, er det sidste: genopret forbindelsen med den gamle profil mod det reelle håndhævelsespunkt, og bekræft at afvisningen kommer fra tilbagekaldelsen. Genopret derefter forbindelsen med et frisk, gyldigt certifikat for at bevise, at du ikke blot brød lytteren. At slette profilen på klienten beviser intet om serverens beslutning, og det gør et vellykket openssl verify-kør heller ikke på en maskine, der aldrig terminerer en tunnel. RFC 6960 definerer, hvad et konformt OCSP-svar indeholder, inklusive de statusværdier, denne test læser.