Revocación del certificado

Existen tres arquitecturas generales sobre cómo los clientes acceden al estado de revocación: basada en extracción , donde los clientes recuperan el estado de revocación en el momento de la validación; basada en inserción , donde los clientes recuperan el estado de revocación antes de la validación y lo almacenan en caché; y asistida por red , donde la comprobación de revocación está estrechamente integrada con el protocolo TLS y es posible que no se necesiten comprobaciones separadas. ^{[ 28 ]}

La comprobación basada en extracción suele presentar problemas de latencia y disponibilidad. Los clientes que realizan comprobaciones basadas en extracción normalmente almacenan en caché las respuestas durante un breve período. Una comprobación puramente basada en extracción combinada con fallos leves no añade seguridad. ^{[ 29 ]}

La verificación basada en el envío de datos consume menos ancho de banda que la verificación basada en la solicitud de datos, pero ofrece mayor disponibilidad y privacidad. Se pueden utilizar diferentes métodos para cada certificado individualmente, lo que permite ajustar el equilibrio: tanto Google Chrome como Mozilla Firefox realizan verificaciones basadas en el envío de datos en un pequeño conjunto de certificados críticos. ^{[ 29 ]}

Una lista de revocación de certificados (CRL) enumera los certificados revocados. Estos son autenticados criptográficamente por la CA emisora. ^{[ 30 ]}

Las CRL tienen problemas de escalabilidad y dependen de que el cliente tenga suficiente acceso a la red para descargarlas antes de comprobar el estado de un certificado. ^{[ 10 ]}

Una CRL contiene información sobre todos los certificados revocados por una CA, lo que significa que los distribuidores y clientes deben incurrir en costos de transferencia por información que probablemente sea irrelevante. ^{[ 31 ]} Un estudio de 2015 encontró que el certificado mediano tenía una CRL con un tamaño de 51 kB, y la CRL más grande era de 76 MB. ^{[ 2 ]}

El Protocolo de estado de certificados en línea (OCSP) permite a los clientes consultar de forma interactiva a un servidor (un respondedor OCSP ) sobre el estado de un certificado, recibiendo una respuesta autenticada criptográficamente por la CA emisora . ^{[ 30 ]} Fue diseñado para abordar problemas con las CRL. ^{[ 31 ]} Una respuesta OCSP típica tiene un tamaño inferior a 1 kB. ^{[ 32 ]}

OCSP presenta problemas de escalabilidad. Depende de que el cliente tenga acceso a la red al momento de verificar el estado de revocación del certificado; además, el respondedor OCSP debe ser accesible y generar respuestas útiles, de lo contrario la verificación fallará y el cliente deberá elegir entre fallar de forma leve o grave. Muchas autoridades de certificación no publican respuestas OCSP útiles para certificados intermedios . ^{[ 10 ]}

Dado que las solicitudes al respondedor se realizan en respuesta a la navegación de los usuarios, los respondedores OCSP pueden obtener información sobre dicha navegación, lo cual representa un problema de privacidad . Además, introduce latencia en las conexiones, ya que es necesario consultar al respondedor antes de poder utilizar una nueva conexión. ^{[ 19 ]}

Un estudio de 2018 encontró que el 1,7 % de las solicitudes a los respondedores no estaban disponibles a nivel de red, y un 2 % adicional produjo respuestas OCSP inutilizables, con una heterogeneidad significativa entre las CA y los puntos de vista del cliente. ^{[ 33 ]}

OCSP stapling es una extensión de TLS que permite que las respuestas OCSP se proporcionen al cliente, junto con el certificado, al iniciar la conexión. ^{[ 31 ]}

El OCSP Stapling puede resolver los desafíos operativos de OCSP, a saber, las solicitudes de red adicionales que causan latencia y degradación de la privacidad. ^{[ 34 ]} Sin embargo, puede ser susceptible a ataques de degradación por parte de un atacante en la ruta. ^{[ 10 ]} RFC 7633 define una extensión que incorpora un requisito en un certificado para ser adjuntado a una respuesta OCSP válida. ^{[ 35 ]} Con esta extensión, el Stapling puede ser efectivo en el caso de que un certificado se haya visto comprometido después de su correcta emisión; sin embargo, si un certificado puede emitirse incorrectamente sin la extensión, el Stapling puede no proporcionar ninguna seguridad. ^{[ 36 ]}

Además de que los clientes y las CA habilitan el stapling y la extensión must-staple, los administradores de servidores también deben tomar medidas para admitir el stapling recuperando regularmente las respuestas y proporcionándolas a los clientes durante el handshake. En 2018, solo Firefox admitía must-staple, y ninguno de los dos servidores web más utilizados ( Apache httpd y Nginx ) admitía el OCSP stapling. ^{[ 37 ]}

CRLite utiliza representaciones estáticas altamente comprimidas de estados de certificados para clientes que emplean filtros de consulta de pertenencia aproximada , lo que permite una producción, distribución y consulta eficientes. ^{[ 38 ]} CRLite permite que los clientes fallen de forma permanente y, dado que todos los clientes recuperan la misma información, CRLite no presenta problemas de privacidad. ^{[ 24 ]}

CRLite es implementable, solo requiere que un agregador recupere las CRL de las CA y luego proporcione la cascada de filtros y sus actualizaciones, y que los clientes lo utilicen; no se necesita ninguna acción por parte de las CA, ni tampoco por parte de los titulares de certificados. ^{[ 24 ]} El agregador no necesita ser un tercero de confianza : la cascada de filtros puede ser auditada para demostrar que refleja con precisión las CRL de entrada. ^{[ 39 ]} Las CA privadas también requieren un manejo especial dentro de CRLite; ^{[ 40 ]} los datos de Firefox sugieren que el 5% de los certificados no están en los registros de CT, ya sea debido a CA privadas o a retrasos en la fusión. ^{[ 41 ]}

En el diseño inicial, CRLite era una cascada de filtros Bloom . ^{[ 38 ]} Un solo filtro construido a partir de una lista de certificados revocados produce falsos positivos . Con un dominio abierto, esto es un problema insuperable para la verificación de revocación. Sin embargo, al usar la Transparencia de Certificados para enumerar todos los certificados no caducados, se puede producir una lista exhaustiva de falsos positivos. Esta lista se usa luego para construir un segundo filtro, que se consulta si un certificado coincide con el primero (y por lo tanto tiene un dominio estrictamente menor); si el segundo filtro no coincide, entonces es un verdadero positivo y el certificado ha sido revocado; sin embargo, una coincidencia en el segundo filtro puede ser un falso negativo, lo que requiere un tercer filtro, y así sucesivamente. Como el universo es finito y el dominio de cada filtro disminuye estrictamente en cada paso, este procedimiento produce una cascada de filtros finita. ^{[ 42 ]}

El estado de revocación de todos los certificados en la PKI web en enero se estimó en un tamaño de 10 MB al usar la cascada de filtros Bloom, con actualizaciones de 580 kB por día. En marzo de 2018, esto había aumentado a 18 MB. ^{[ 29 ]} En una simulación con 100 millones de certificados, una tasa de expiración diaria del 1 % y una tasa de revocación del 2 %, CRLite requirió un aprovisionamiento inicial de 3,1 MB y luego 408 kB por día para actualizaciones. ^{[ 43 ]} Mozilla, en una implementación de prueba de CRLite, encontró en 2024 que la tasa de descarga amortizada fue de 26 MB durante 10 días. ^{[ 38 ]}

CRLite fue posteriormente revisado para utilizar un algoritmo novedoso y más eficiente, denominado clubcards , que redujo el uso de datos, así como al observar que las revocaciones no se distribuyen uniformemente entre las CA (es decir, algunas CA tienen tasas de revocación persistentemente más altas que otras) ni a lo largo del tiempo (por ejemplo, debido a eventos de revocación masiva), y que, al particionar los certificados según estos parámetros, se puede mejorar la eficiencia. ^{[ 44 ]} La descarga inicial de los datos de prueba de membresía de clubcard en 2024 fue de 7,0 MB, cubriendo 903 millones de certificados válidos y 8,7 millones de certificados revocados; las actualizaciones, producidas cada seis horas, eran en promedio de 95,5 kB, pero podían comprimirse a 26,0 kB. Con solo la partición por emisor, esto está dentro del 12 % del límite inferior teórico; con una partición más sofisticada que también utiliza fechas de vencimiento/emisión, la cantidad restante para explotar alcanza hasta el 116 %. ^{[ 45 ]}

Después de una implementación de prueba detrás de una bandera de características del diseño inicial de CRLite en Firefox versión 68, ^{[ 38 ]} Mozilla implementó el diseño revisado en la versión 137 de Firefox, y en agosto de 2025 deshabilitó OCSP para certificados validados de dominio en Firefox 142, ^{[ 7 ]} haciendo efectivamente el cambio al uso de producción de CRLite. ^{[ 46 ]} En una prueba de laboratorio, se encontró que la verificación de revocación tomaba tan solo 10 μs por certificado, y, a partir de datos de campo, los tiempos promedio de handshake TLS se redujeron de 172,4 ms a 143,4 ms, atribuido a no necesitar recuperar una respuesta OCSP. ^{[ 45 ]}

Let's Revoke utiliza vectores de bits de estados de revocación (llamados vectores de revocación de certificados o CRV) para permitir que los clientes recuperen de manera eficiente grandes cantidades de estados de revocación. ^{[ 4 ]} Las CA generan CRV para sus propios certificados, con un CRV por fecha de vencimiento. El mantenimiento de CRV para las CA es lineal con respecto al número de certificados emitidos. Las CA deben agregar un nuevo campo, un número de revocación, a cada certificado emitido, lo que permite que los certificados de una sola CA se identifiquen mediante una tupla de fecha de vencimiento del certificado y número de revocación; esta tupla permite que un cliente localice de manera eficiente un bit que indica el estado del certificado identificado dentro del CRV. Los CRV pueden comprimirse; se espera que se compriman muy bien, ya que la mayoría de los bits estarán desactivados la mayor parte del tiempo. Como cada CRV está asociado con una fecha de vencimiento fija, los CRV antiguos se pueden descartar de manera eficiente. Las actualizaciones de los CRV se agrupan, con la fecha y hora de actualización y firma para su distribución a los clientes. ^{[ 47 ]} Las actualizaciones pueden ser de tres formas, y la elección óptima depende de la tasa de revocación, lo que permite tanto un funcionamiento normal eficiente como eventos de revocación masiva. ^{[ 48 ]}

Se espera que los CRV sean lo suficientemente pequeños como para permitir la verificación basada en el envío, pero los clientes más restringidos aún pueden realizar verificaciones basadas en la extracción, accediendo solo a CRV seleccionados o aplazando la recuperación de CRV hasta la validación del certificado. ^{[ 49 ]} Un cliente que utiliza Let's Revoke con verificación basada en el envío puede fallar completamente para cualquier certificado con un número de revocación. ^{[ 24 ]} El impacto en la privacidad y la disponibilidad de Let's Revoke dependen de la arquitectura: si todas las verificaciones son basadas en el envío, entonces no hay fuga de privacidad y una vulnerabilidad reducida a la denegación de servicio o al tiempo de inactividad; sin embargo, si se utilizan verificaciones basadas en la extracción, se filtra cierta información sobre las actividades del usuario (en la forma en que se accede a los CRV), y los CRV pueden ser inaccesibles en el momento de la validación. ^{[ 24 ]}

En una simulación con 100 millones de certificados, una tasa de vencimiento diaria del 1 % y una tasa de revocación del 2 %, Let's Revoke requirió un aprovisionamiento inicial de 2,2 MB y luego 114 kB por día para actualizaciones. ^{[ 50 ]}

Let's Revoke aún no se ha implementado ampliamente. ^{[ 10 ]} Además de las implementaciones de los clientes, requiere que las CA realicen cambios operativos, ^{[ 51 ]} y no proporciona tanta información como las CRL o OCSP (solo un bit por certificado para la validez); las CRL o OCSP aún pueden usarse para complementar Let's Revoke y proporcionar esa información adicional. ^{[ 52 ]} La implementación puede realizarse CA por CA, y los clientes se benefician del comportamiento de tolerancia a fallos de forma incremental. Debido a la eficiencia de las CRV sobre las CRL y las respuestas OCSP, las CA pueden verse incentivadas a implementar Let's Revoke. ^{[ 51 ]}

Las técnicas de recuperación de información privada pueden mitigar la preocupación por la privacidad con comprobaciones basadas en extracción. ^{[ 53 ]} En lugar de que los clientes realicen comprobaciones de revocación, un dispositivo intermedio podría centralizar el costo de la comprobación de revocación y amortizarlo entre muchas conexiones; los clientes no necesitan dedicar almacenamiento a la información de revocación. ^{[ 54 ]} Otra propuesta consistía en transmitir información de revocación por radio FM . ^{[ 42 ]}