OCSP fronte a unha CRL: como funciona realmente cada comprobación de revocación

Unha destas dúas comprobacións de revocación devolve unha resposta asinada sobre un só certificado, e a outra devolve unha lista asinada que se descarga enteira. Ambas deben dicirlle a un verificador se unha credencial segue sendo de confianza, e ambas fallan de maneiras que non se parecen en nada. A orde seguinte segue o que un operador atopa realmente en produción, comezando polos bytes no cable e rematando cunha pasarela que rexeita unha conexión. Saltar un paso é a forma en que un despregue acaba cunha política de revocación que só existe no papel.

Paso 1: Que devolve cada comprobación e canto tempo segue sendo utilizábel

Unha CRL publícase como un único obxecto asinado que cobre todos os certificados que un emisor revogou, así que un verificador a descarga unha vez e reutilízaa ata que pasa o nextUpdate da lista. Unha resposta OCSP é máis estreita: responde exactamente por un certificado e leva thisUpdate, producedAt e normalmente tamén nextUpdate. Esa diferenza goberna todo o demais. Unha CRL na caché caduca en silencio, porque o ficheiro aínda se analiza e a súa sinatura aínda se verifica, mentres que unha resposta OCSP caducada é obviamente inútil no momento en que se len as súas marcas de tempo.

Por iso a caché é o primeiro que hai que fixar: que compoñente garda a copia e a que teito obedece esa copia. Nunha pasarela o teito debería ser nextUpdate menos unha marxe de seguridade, nunca o que suxira por casualidade unha cabeceira de caché HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate imprime ambas as datas, e unha lista cuxo nextUpdate xa está no pasado debe tratarse como ausente e non só como antiga.

Paso 2: Cara a onde apunta o certificado ao cliente

O certificado folla adoita levar dúas pistas: unha extensión de punto de distribución de CRL e unha entrada de acceso á información da autoridade para OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints imprime a primeira, e a segunda está baixo a sección AIA de openssl x509 -in client.pem -noout -text. Calquera das dúas extensións é un punteiro, non unha obriga. Un cliente que nunca implementa a comprobación de revocación conectarase perfectamente a un certificado cuxas extensións nomean un respondente que leva un ano morto.

Os puntos de distribución adoitan nomear un host interno que só se resolve dentro dun segmento de rede, e algúns clientes antigos rexeitan as URL ldap sen máis. Probe a accesibilidade desde o host que termina o túnel, non desde o seu propio portátil, porque ese é o único punto de vista cuxo fallo realmente importa.

Paso 3: Escolla fail-closed ou fail-open antes da caída

Un respondente inalcanzábel ou unha lista caducada obrigan a decidir: rexeitar a conexión, ou aceptala e rexistrar o oco. O subcomando verify de OpenSSL fai explícita a opción estrita, porque engadir -crl_check converte unha CRL non dispoñíbel en unable to get certificate CRL e unha verificación fallida. O soft-fail na maioría das pilas non é unha bandeira en absoluto, é a ausencia da comprobación, e por iso mesmo chega por accidente.

Para ver que comportamento ten realmente un cliente, quite o respondente e volva conectar. Se o túnel segue levantándose, busque a liña de rexistro que anotou a comprobación omitida e pregúntese se alguén lería esa liña durante un incidente. O mesmo provedor pode diferir por protocolo, cun cliente IKEv2 e un cliente OpenVPN nunha máquina lendo axustes de configuración non relacionados.

Paso 4: Demostre que a comprobación se executa onde se admite o tráfico

Atope o proceso que termina ou autoriza a conexión e pregúntelle pola liña de configuración que habilita a comprobación de revocación. Unha pasarela que valida a cadea pero nunca pregunta pola revocación aplica unha política distinta da que hai na súa documentación, e ningunha captura de pantalla dunha cadea de certificados demostra o contrario. OpenVPN escribe a opción como crl-verify; strongSwan mantén as buscas de CRL e OCSP baixo a configuración da CA, onde se establecen crl_uris ou ocsp_uris. Se non pode sinalar ningunha das dúas, supoña que a comprobación está ausente.

Unha resposta OCSP só conta cando a asinou a CA emisora, ou cando a asinou un respondente que ten o uso de chave estendido OCSPSigning delegado por esa CA, así que unha resposta dun servizo non relacionado non demostra nada. Se vostede mesmo executa o respondente, monitoríceo como unha dependencia dura, porque un só servizo morto convértese nunha caída para cada cliente fail-closed á vez.

Paso 5: Revogue un certificado a propósito

Colla un certificado de proba, revógueo pola mesma canle que usa produción e pregúntelle directamente ao respondente. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text debería informar de Cert Status: revoked xunto cunha hora de revocación, e unha resposta good significa que a súa revocación non chegou ao respondente que consultan os seus clientes. Despois execute openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem para ver a mesma decisión pola ruta da lista. Lea a cadea do motivo en lugar do código de saída, porque un rexeitamento por revocación e un erro de cadea acaban ambos en fallo.

O paso que realmente importa é o último: volva conectar co perfil antigo contra o punto de aplicación real e confirme que o rexeitamento vén da revocación. Despois volva conectar cun certificado novo e válido para demostrar que non se limitou a romper o oínte. Borrar o perfil no cliente non demostra nada sobre a decisión do servidor, e tampouco o fai unha execución correcta de openssl verify nunha máquina que nunca termina un túnel. RFC 6960 define que contén unha resposta OCSP conforme, incluídos os valores de estado que le esta proba.