OCSP davant d’una CRL: com funciona realment cada comprovació de revocació

Una d’aquestes dues comprovacions de revocació retorna una resposta signada sobre un sol certificat, i l’altra retorna una llista signada que es descarrega sencera. Totes dues han de dir a un verificador si una credencial encara és de confiança, i totes dues fallen de maneres que no s’assemblen gens. L’ordre següent segueix el que un operador troba realment en producció, començant pels bytes al cable i acabant amb una passarel·la que refusa una connexió. Saltar-se un pas és com un desplegament acaba amb una política de revocació que només existeix sobre el paper.

Pas 1: Què retorna cada comprovació i quant de temps resta utilitzable

Una CRL es publica com un sol objecte signat que cobreix tots els certificats que un emissor ha revocat, així que un verificador la baixa un cop i la reutilitza fins que passa el nextUpdate de la llista. Una resposta OCSP és més estreta: respon exactament per a un certificat i porta thisUpdate, producedAt i normalment també nextUpdate. Aquesta diferència ho governa tot la resta. Una CRL desada a la memòria cau caduca en silenci, perquè el fitxer encara s’analitza i la seva signatura encara es verifica, mentre que una resposta OCSP caducada és òbviament inútil en el moment que en llegeixes les marques de temps.

Per tant, la memòria cau és el primer que cal fixar: quin component guarda la còpia i a quin sostre obeeix aquesta còpia. En una passarel·la el sostre hauria de ser nextUpdate menys un marge de seguretat, mai el que suggereixi per casualitat una capçalera de memòria cau HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate imprimeix les dues dates, i una llista el nextUpdate de la qual ja és al passat s’ha de tractar com a absent i no només com a antiga.

Pas 2: Cap on el certificat apunta el client

El certificat full normalment porta dos indicis: una extensió de punt de distribució de CRL i una entrada d’accés a la informació de l’autoritat per a OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints imprimeix el primer, i el segon es troba sota la secció AIA de openssl x509 -in client.pem -noout -text. Qualsevol de les dues extensions és un punter, no una obligació. Un client que no implementa mai la comprovació de revocació es connectarà perfectament bé contra un certificat les extensions del qual anomenen un responedor que és mort des de fa un any.

Els punts de distribució sovint anomenen un amfitrió intern que només es resol dins d’un segment de xarxa, i alguns clients antics refusen directament les URL ldap. Proveu l’abastabilitat des de l’amfitrió que acaba el túnel, no des del vostre portàtil, perquè aquest és l’únic punt de vista la fallada del qual importa de debò.

Pas 3: Trieu fail-closed o fail-open abans de la caiguda

Un responedor inabastable o una llista caducada obliguen a decidir: refusar la connexió, o acceptar-la i registrar el buit. La subcomanda verify d’OpenSSL fa explícita l’opció estricta, perquè afegir -crl_check converteix una CRL no disponible en unable to get certificate CRL i una verificació fallida. El soft-fail a la majoria d’estructures no és cap indicador, és l’absència de la comprovació, i per això mateix arriba per accident.

Per veure quin comportament té realment un client, traieu el responedor i torneu a connectar. Si el túnel encara s’aixeca, trobeu la línia de registre que va anotar la comprovació omesa i pregunteu-vos si algú la llegiria durant un incident. Un mateix fabricant pot diferir per protocol, amb un client IKEv2 i un client OpenVPN en una màquina que llegeixen paràmetres de configuració no relacionats.

Pas 4: Demostreu que la comprovació s’executa on s’admet el trànsit

Trobeu el procés que acaba o autoritza la connexió i pregunteu-li per la línia de configuració que habilita la comprovació de revocació. Una passarel·la que valida la cadena però que mai no pregunta per la revocació aplica una política diferent de la que hi ha a la vostra documentació, i cap captura de pantalla d’una cadena de certificats no demostra el contrari. OpenVPN escriu l’opció com a crl-verify; strongSwan manté les cerques de CRL i OCSP sota la configuració de la CA, on s’estableixen crl_uris o ocsp_uris. Si no podeu assenyalar-ne cap, suposeu que la comprovació és absent.

Una resposta OCSP només compta quan l’ha signada la CA emissora, o quan l’ha signada un responedor que té l’ús de clau estès OCSPSigning delegat per aquesta CA, així que una resposta d’un servei no relacionat no demostra res. Si executeu vosaltres mateixos el responedor, monitoreu-lo com una dependència dura, perquè un sol servei mort es converteix en una caiguda per a cada client fail-closed alhora.

Pas 5: Revogueu un certificat a propòsit

Agafeu un certificat de prova, revogueu-lo pel mateix canal que fa servir la producció i pregunteu directament al responedor. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text hauria d’informar de Cert Status: revoked juntament amb una hora de revocació, i una resposta good vol dir que la vostra revocació no va arribar al responedor que consulten els vostres clients. A continuació executeu openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem per veure la mateixa decisió pel camí de la llista. Llegiu la cadena del motiu en lloc del codi de sortida, perquè un rebuig per revocació i un error de cadena tots dos acaben en fallada.

El pas que realment importa és l’últim: torneu-vos a connectar amb el perfil antic contra el punt d’aplicació real i confirmeu que el rebuig ve de la revocació. Després torneu-vos a connectar amb un certificat nou i vàlid per demostrar que no heu trencat només l’oient. Esborrar el perfil al client no demostra res sobre la decisió del servidor, i tampoc no ho fa una execució correcta de openssl verify en una màquina que mai no acaba un túnel. RFC 6960 defineix què conté una resposta OCSP conforme, incloent-hi els valors d’estat que llegeix aquesta prova.