OCSP kontra CRL: hogyan működik valójában az egyes visszavonás-ellenőrzések
Az OCSP-válasz egy tanúsítvány aláírt állapota; a CRL egy letöltött lista. Az elosztás, a gyorsítótárazás és a hiba esetén mutatott viselkedés az, amiben eltérnek.
E két visszavonás-ellenőrzés egyike egyetlen tanúsítványról ad aláírt választ, a másik pedig egy aláírt listát ad, amelyet teljes egészében letölt. Mindkettőnek meg kell mondania egy ellenőrzőnek, hogy egy hitelesítő adat még megbízható-e, és mindkettő olyan módokon hibázik, amelyek egyáltalán nem hasonlítanak egymásra. Az alábbi sorrend azt követi, amivel egy üzemeltető a termelésben valóban találkozik, a hálózaton lévő bájtoktól kezdve egy kapcsolatot elutasító átjáróig. Egy lépés kihagyása az az út, amelyen egy telepítés olyan visszavonási szabályzattal marad, amely csak papíron létezik.
1. lépés: Mit ad vissza az egyes ellenőrzések, és meddig marad használható
A CRL egyetlen aláírt objektumként jelenik meg, amely lefedi az összes tanúsítványt, amelyet a kibocsátó visszavont, így az ellenőrző egyszer letölti, és újra felhasználja, amíg a lista nextUpdate értéke el nem múlik. Az OCSP-válasz szűkebb: pontosan egy tanúsítványra válaszol, és thisUpdate, producedAt, valamint általában nextUpdate mezőt is hordoz. Ez a különbség vezérli az összes többit. A gyorsítótárazott CRL csendben elavul, mert a fájl még mindig feldolgozható, és az aláírása még mindig ellenőrizhető, míg a lejárt OCSP-válasz nyilvánvalóan értéktelen abban a pillanatban, amikor elolvassa az időbélyegjeit.
A gyorsítótárazás tehát az első dolog, amit rögzíteni kell: melyik összetevő tartja a másolatot, és milyen felső korlátnak engedelmeskedik az a másolat. Egy átjárón a felső korlát a nextUpdate mínusz egy biztonsági ráhagyás legyen, soha ne az, amit egy HTTP gyorsítótár-fejléc véletlenül javasol. openssl crl -in issuer.crl -noout -lastupdate -nextupdate kiírja mindkét dátumot, és egy listát, amelynek nextUpdate értéke már a múltban van, hiányzóként kell kezelni, nem csupán régiként.
2. lépés: Hová irányítja a tanúsítvány az ügyfelet
A levéltanúsítvány általában két nyomot hordoz: egy CRL-elosztási pont kiterjesztést és egy szolgáltatói információhozzáférési bejegyzést az OCSP-hez. openssl x509 -in client.pem -noout -ext crlDistributionPoints kiírja az elsőt, a második pedig a openssl x509 -in client.pem -noout -text kimenetének AIA szakasza alatt található. Mindkét kiterjesztés mutató, nem kötelezettség. Az az ügyfél, amely soha nem valósítja meg a visszavonás-ellenőrzést, tökéletesen csatlakozik egy olyan tanúsítványhoz, amelynek kiterjesztései egy éve halott válaszadót neveznek meg.
Az elosztási pontok gyakran olyan belső gazdagépet neveznek meg, amely csak egy hálózati szegmensen belül oldható fel, és néhány régebbi ügyfél az ldap URL-eket egyenesen elutasítja. Az elérhetőséget abból a gazdagépből tesztelje, amely lezárja az alagutat, ne a saját laptopjából, mert ez az egyetlen nézőpont, amelynek a hibája valóban számít.
3. lépés: Válasszon fail-closed vagy fail-open viselkedést a kiesés előtt
Egy elérhetetlen válaszadó vagy egy lejárt lista döntésre kényszerít: utasítsa el a kapcsolatot, vagy fogadja el és rögzítse a hiányt. Az OpenSSL verify alparancsa egyértelművé teszi a szigorú választást, mert a -crl_check hozzáadása egy elérhetetlen CRL-t unable to get certificate CRL és sikertelen ellenőrzéssé tesz. A puha hiba a legtöbb stackben egyáltalán nem kapcsoló, hanem az ellenőrzés hiánya, és éppen ezért kerül be véletlenül.
Ahhoz, hogy lássa, milyen viselkedése van valójában egy ügyfélnek, vegye ki a válaszadót, és csatlakozzon újra. Ha az alagút mégis feljön, keresse meg a naplósort, amely rögzítette a kihagyott ellenőrzést, majd kérdezze meg, olvasná-e valaki azt a sort egy incidens során. Ugyanaz a szállító protokollonként eltérhet: egy IKEv2-ügyfél és egy OpenVPN-ügyfél ugyanazon a gépen egymással nem összefüggő konfigurációs kapcsolókat olvas.
4. lépés: Bizonyítsa, hogy az ellenőrzés ott fut, ahol a forgalmat beengedik
Keresse meg azt a folyamatot, amely lezárja vagy engedélyezi a kapcsolatot, majd kérdezze meg tőle azt a konfigurációs sort, amely engedélyezi a visszavonás-ellenőrzést. Egy átjáró, amely érvényesíti a láncot, de soha nem kérdez a visszavonásról, más szabályzatot alkalmaz, mint a dokumentációjában szereplő, és egyetlen tanúsítványlánc-képernyőkép sem bizonyítja az ellenkezőjét. Az OpenVPN az opciót crl-verify alakban írja; a strongSwan a CRL- és OCSP-kereséseket a CA konfigurációja alatt tartja, ahol a crl_uris vagy ocsp_uris beállítás található. Ha egyikre sem tud rámutatni, feltételezze, hogy az ellenőrzés hiányzik.
Egy OCSP-válasz csak akkor érvényes, ha a kibocsátó CA írta alá, vagy ha egy olyan válaszadó írta alá, amely rendelkezik a CA által delegált OCSPSigning kiterjesztett kulcshasználattal, így egy nem kapcsolódó szolgáltatás válasza semmit sem bizonyít. Ha saját maga üzemelteti a válaszadót, kemény függőségként figyelje, mert egyetlen halott szolgáltatás egyszerre válik kieséssé minden fail-closed ügyfél számára.
5. lépés: Vonjon vissza szándékosan egy tanúsítványt
Vegyen egy teszttanúsítványt, vonja vissza ugyanazon a csatornán, amelyet a termelés használ, és kérdezze meg közvetlenül a válaszadót. A openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text parancsnak jelentenie kell a Cert Status: revoked értéket egy visszavonási idővel együtt, a good válasz pedig azt jelenti, hogy a visszavonás nem érte el azt a válaszadót, amelyet az ügyfelei kérdeznek. Ezután futtassa a openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem parancsot, hogy ugyanazt a döntést a lista útvonalán lássa. A kilépési kód helyett az ok-karakterláncot olvassa, mert a visszavonás miatti elutasítás és a lánchiba is kudarccal végződik.
Az a lépés, amely valóban számít, az utolsó: csatlakozzon újra a régi profillal a valódi érvényesítési pont ellen, és erősítse meg, hogy az elutasítás a visszavonásból ered. Ezután csatlakozzon újra egy friss, érvényes tanúsítvánnyal, hogy bizonyítsa, nem csupán a figyelőt törte el. A profil törlése az ügyfélen semmit sem bizonyít a kiszolgáló döntéséről, és egy sikeres openssl verify futtatás sem egy olyan gépen, amely soha nem zár le alagutat. RFC 6960 határozza meg, mit tartalmaz egy megfelelő OCSP-válasz, beleértve azokat az állapotértékeket, amelyeket ez a teszt olvas.