En criptografía de clave pública , un certificado puede revocarse antes de que caduque, lo que indica que ya no es válido. Sin revocación, un atacante podría explotar dicho certificado comprometido o emitido incorrectamente hasta que caduque. Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública . La revocación la realiza la autoridad certificadora emisora , que produce una declaración de revocación autenticada criptográficamente .
Para distribuir información de revocación a los clientes, la oportunidad del descubrimiento de la revocación (y por lo tanto la ventana para que un atacante explote un certificado comprometido) se compensa con el uso de recursos al consultar los estados de revocación y las preocupaciones de privacidad. Si la información de revocación no está disponible (ya sea debido a un accidente o un ataque), los clientes deben decidir si realizar una falla total y tratar un certificado como si estuviera revocado (y así degradar la disponibilidad ) o fallar suavemente y tratarlo como no revocado ( y permitir a los atacantes eludir la revocación).
Debido al costo de las comprobaciones de revocación y al impacto en la disponibilidad de servicios remotos potencialmente poco confiables, los navegadores web limitan las comprobaciones de revocación que realizarán y fallarán suavemente cuando lo hagan. Las listas de revocación de certificados consumen demasiado ancho de banda para el uso rutinario y el Protocolo de estado de certificados en línea presenta problemas de latencia de conexión y privacidad. Se han propuesto otros esquemas, pero aún no se han implementado con éxito para permitir una verificación infalible.
La vulnerabilidad Heartbleed , revelada en 2014, provocó una revocación masiva de certificados, ya que es posible que se hayan filtrado sus claves privadas. GlobalSign revocó más del 50% de sus certificados emitidos. StartCom fue criticado por emitir certificados gratuitos pero luego cobrar por su revocación. [1]
Un estudio de 2015 encontró una tasa general de revocación del 8 % para los certificados utilizados en la Web, [2] aunque esta tasa puede haber aumentado debido a Heartbleed. [3]
A pesar de que la seguridad web es una prioridad para la mayoría de los navegadores , debido a los requisitos de latencia y ancho de banda asociados con OCSP y CRL, los navegadores imponen límites a la verificación del estado de los certificados. [4] En 2015, Google Chrome solo verificó activamente los certificados de validación extendida , ningún navegador móvil realizó ninguna verificación de validez y ningún navegador verificó completamente todos los certificados. [5] Chrome y Firefox realizan comprobaciones push para un pequeño conjunto de dominios considerados críticos. [6] Los navegadores muestran poco acuerdo en los casos extremos en torno a la validez del certificado, lo que puede confundir incluso a los usuarios experimentados. [7]
La cantidad de certificados en Web PKI aumentó enormemente durante la última parte de la década de 2010, de 30 millones en enero de 2017 a 434 millones en enero de 2020. Un factor importante en este crecimiento es que Let's Encrypt proporciona certificados validados de dominio gratuitos . El tamaño del conjunto de certificados potencialmente revocables impone requisitos sobre la escalabilidad del mecanismo de revocación. [4]
Chuat et al. (2020) califican la revocación como "notoriamente desafiante". [8] En 2022, RFC 9325 caracterizó la revocación de certificados como un problema importante sin "una solución completa y eficiente". Se recomienda OCSP y grapado OCSP como "base para una posible solución". [9]
La revocación de certificados es "una herramienta importante" para hacer frente a ataques y compromisos accidentales. RFC 9325 impone un requisito normativo a las implementaciones de TLS para tener algún medio para desconfiar de los certificados. [9] Sin revocación, un atacante puede utilizar un certificado comprometido para hacerse pasar por su propietario hasta que caduque. [4]
Es posible que la revocación no sea necesaria para certificados con una vida útil suficientemente corta, aproximadamente del orden de horas a días, lo que es comparable a la vida útil de una respuesta OCSP. La emisión frecuente de certificados asociada generalmente requiere automatización (por ejemplo, el protocolo ACME) y puede sobrecargar otros elementos infraestructurales (por ejemplo, registros de transparencia). [10] Los certificados de corta duración también presentan complicaciones con la reanudación de la conexión TLS , aunque no necesariamente de manera insuperable. [11]
La revocación puede ser iniciada por el titular del certificado (que, por ejemplo, puede saber que una clave privada ha sido comprometida), quien informa a la CA. Luego, la CA produce y distribuye certificaciones autenticadas criptográficamente de que el certificado ha sido revocado. [12] Los requisitos de CA/B también permiten a una CA revocar certificados de forma autónoma si es consciente de una posibilidad de compromiso. [13] Cualquier persona puede presentar dichas pruebas. [14]
Los estados de revocación generalmente no se conservan ni archivan por mucho tiempo después de la expiración del certificado, lo que dificulta la investigación y la auditoría de los comportamientos de revocación. [15] Una propuesta para resolver esto implica enviar 'postcertificados' a los registros de Transparencia de Certificados para cada revocación, lo que también permitiría que la revocación se realice sin acción por parte de una CA; [16] una propuesta alternativa, también basada en la transparencia de los certificados, implica que las CA envíen CRV a los registros de CT. [17]
Si el estado de revocación no está disponible (lo que puede ser benigno o debido a un ataque), un cliente se enfrenta a un dilema al evaluar un certificado: puede fallar suavemente y asumir que el certificado aún es válido; o puede fallar y asumir que el certificado ha sido revocado. Esta es una compensación entre seguridad y disponibilidad: la falla suave permite ataques de degradación , mientras que la falla dura permite la denegación de servicio (de ataques) o causa indisponibilidad. [18]
Un atacante con la capacidad de presentar un certificado comprometido probablemente también tenga la capacidad de impedir que el cliente realice una verificación del estado de revocación en línea; en este caso, el fallo suave no proporciona ninguna protección. Los navegadores han elegido esta parte del dilema y han preferido la disponibilidad a la seguridad. [19]
Los fallos duros pueden introducir nuevos vectores de ataque de denegación de servicio. Por ejemplo, si los clientes esperan el grapado de OCSP y, de lo contrario, fallan, una denegación de servicio contra los respondedores de OCSP se amplifica a una denegación de servicio contra todos los servicios que deseen utilizar esas respuestas de OCSP. [10]
Hay dos escenarios para la evaluación del uso de recursos: condiciones normales y eventos de revocación masiva. Los esquemas de revocación deben ser eficientes en condiciones normales y funcionales durante eventos de revocación masiva. [4]
La recuperación de información de revocación genera costos de ancho de banda y latencia para los clientes. [20]
Durante el evento de revocación masiva Heartbleed de 2014, donde las tasas de revocación aumentaron del 1 % al 11 %, Cloudflare estimó que el ancho de banda que GlobalSign utilizó para distribuir las CRL podría haber costado 400 000 USD (equivalente a 510 000 USD en 2023 [21] ). [22]
Si el estado de revocación no se recupera recientemente para cada verificación (por ejemplo, debido al almacenamiento en caché o recuperaciones periódicas), hay un retraso entre la revocación de un certificado y la garantía de que todos los clientes estarán al tanto de la revocación. Esto presenta una compensación entre latencia, eficiencia y seguridad: tiempos de caché más prolongados o actualizaciones menos frecuentes utilizan menos recursos y reducen la latencia, pero significan que se puede abusar de un certificado comprometido durante más tiempo. [23]
Los clientes que realizan comprobaciones basadas en extracción pueden filtrar la información de navegación del usuario a terceros, concretamente al distribuidor de información de revocación. [24]
Es deseable evitar la creación de un tercero de confianza en una PKI. Si un actor dentro de un esquema es auditable, entonces los clientes (o agentes que actúan en nombre de los clientes) pueden verificar de manera demostrable que un actor se está comportando correctamente. [25]
Una distribución del estatus de revocación que impone pesadas cargas a las CA puede no tener éxito, especialmente si la CA no puede obtener beneficios compensatorios de la implementación. Reducir el número de partes que deben realizar cambios para adoptarlo también facilita la implementación: potencialmente involucrados están las CA, los clientes, los administradores de servidores y los productores de software de servidor. La compatibilidad hacia adelante es un arma de doble filo, ya que los clientes y servidores antiguos no se verán afectados por un nuevo esquema, pero es posible que sus usuarios no se den cuenta de que se están perdiendo los beneficios de la revocación. [26]
Hay tres arquitecturas amplias 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; basado en push , 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 verificación de revocación está estrechamente integrada con el protocolo TLS y es posible que no se necesiten verificaciones por separado. [27]
La comprobación basada en extracción suele tener problemas de latencia y disponibilidad. Los clientes que realizan comprobaciones basadas en extracción normalmente almacenarán en caché las respuestas durante un período breve. Una verificación puramente basada en extracción combinada con fallas suaves no agrega seguridad. [28]
La verificación basada en push es menos eficiente en cuanto al ancho de banda que la verificación basada en pull, pero gana en disponibilidad y privacidad. Se pueden utilizar diferentes métodos certificado por certificado, lo que permite ajustar la compensación: tanto Google Chrome como Mozilla Firefox realizan comprobaciones push en un pequeño conjunto de certificados críticos. [28]
Una lista de revocación de certificados (CRL) enumera los certificados revocados. Están autenticados criptográficamente por la CA emisora. [29]
Las CRL tienen problemas de escalabilidad y dependen de que el cliente tenga suficiente acceso a la red para descargarlas antes de verificar el estado de un certificado. [9]
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. [30] 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 preguntar interactivamente a un servidor (un respondedor OCSP ) sobre el estado de un certificado, recibiendo una respuesta autenticada criptográficamente por la CA emisora. [29] Fue diseñado para abordar problemas con las CRL. [30] Una respuesta típica de OCSP es inferior a 1 kB. [31]
OCSP sufre 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 producir respuestas utilizables; de lo contrario, la verificación fallará y el cliente deberá elegir entre falla suave y falla dura. Muchas autoridades certificadoras no publican respuestas OCSP útiles para certificados intermedios . [9]
Como las solicitudes al respondedor se realizan en respuesta a la navegación de los usuarios, los respondedores de OCSP pueden conocer la navegación de los usuarios, lo cual es un problema de privacidad . También introduce latencia en las conexiones, ya que se debe consultar al respondedor antes de poder utilizar una nueva conexión. [18]
Un estudio de 2018 encontró que el 1,7% de las solicitudes a los socorristas no estaban disponibles a nivel de red, y otro c. El 2% produjo respuestas OCSP inutilizables, con una heterogeneidad significativa entre las CA y los puntos de vista de los clientes. [32]
El grapado OCSP es una extensión TLS que proporciona respuestas OCSP al cliente, junto con el certificado, al inicio de la conexión. [30]
El grapado de OCSP puede resolver los desafíos operativos de OCSP, es decir, solicitudes de red adicionales que causan latencia y degradación de la privacidad. [33] Sin embargo, puede ser susceptible a ataques de degradación por parte de un atacante en ruta. [9] RFC 7633 define una extensión que incorpora un requisito en un certificado que se grapará a una respuesta OCSP válida. [34] Con esta extensión, el grapado puede ser efectivo en el caso en que un certificado se haya visto comprometido después de su emisión adecuada; sin embargo, si un certificado puede emitirse incorrectamente sin la extensión, es posible que el grapado no brinde ninguna seguridad. [35]
Más allá de que los clientes y las CA permitan el grapado y la extensión imprescindible, los administradores del servidor también deben tomar medidas para admitir el grapado recuperando respuestas periódicamente y luego proporcionándolas a los clientes durante el protocolo de enlace. En 2018, solo Firefox admitía el grapado obligatorio, y ninguno de los dos servidores web más utilizados ( Apache httpd y Nginx ) admitía el grapado OCSP. [36]
CRLite proporciona estados de revocación mediante una cascada de filtros Bloom . Un único filtro construido a partir de una lista de certificados revocados produce falsos positivos . Con un dominio abierto, este es un problema insuperable para la verificación de revocaciones. Sin embargo, al utilizar Certificate Transparency para enumerar todos los certificados no vencidos, se puede generar una lista exhaustiva de falsos positivos. Esta lista luego se utiliza para construir un segundo filtro, que se consulta si un certificado coincide con el primero (y por lo tanto tiene un dominio estrictamente más pequeño); 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. [37]
CRLite permite a los clientes fallar con fuerza. [23]
Se estimó que el estado de revocación de todos los certificados en Web PKI en enero era de 10 MB cuando se usaba la cascada de filtros Bloom, con actualizaciones de 580 kB por día. En marzo de 2018, esto había aumentado a 18 MB. [28] En una simulación con 100 millones de certificados, una tasa de vencimiento diario del 1% y una tasa de revocación del 2%, CRLite requirió una provisión inicial de 3,1 MB y luego 408 kB por día para las actualizaciones. [38]
Como todos los clientes recuperan la misma información, CRLite no tiene preocupaciones de privacidad. [23]
CRLite aún no se ha implementado ampliamente. [9] Sin embargo, es implementable y 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 las utilicen; no es necesaria ninguna acción por parte de las CA ni tampoco por parte de los titulares de certificados. [23] No es necesario que el agregador sea un tercero de confianza : la cascada de filtros se puede auditar 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]
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 en el 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 identificar los certificados de una única CA mediante una tupla de fecha de vencimiento del certificado y número de revocación; esta tupla permite a un cliente localizar eficientemente un bit que proporciona el estado del certificado identificado dentro del CRV. Los CRV pueden estar comprimidos; se espera que se compriman muy bien, ya que la mayoría de los bits estarán desarmados 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 realizan por lotes, con la fecha y hora de la actualización firmadas para su distribución a los clientes. [41] Las actualizaciones pueden realizarse en una 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. [42]
Se espera que los CRV sean lo suficientemente pequeños como para permitir la verificación basada en inserción, pero los clientes más restringidos aún pueden realizar verificaciones basadas en extracción, accediendo solo a CRV seleccionadas o posponiendo la recuperación de CRV hasta la validación del certificado. [43] Un cliente que utiliza Let's Revoke con verificación basada en push puede fallar en cualquier certificado con un número de revocación. [23] El impacto en la privacidad y la disponibilidad de Let's Revoke dependen de la arquitectura: si todas las comprobaciones se basan en push, entonces no hay fugas de privacidad y se reduce la vulnerabilidad a la denegación de servicio o el tiempo de inactividad; Sin embargo, si se utilizan comprobaciones basadas en extracción, se filtra cierta información sobre las actividades del usuario (en la forma en que se accede a los CRV) y es posible que los CRV sean inaccesibles en el momento de la validación. [23]
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ó una provisión inicial de 2,2 MB y luego 114 kB por día para las actualizaciones. [44]
Let's Revoke aún no se ha implementado ampliamente. [9] Además de las implementaciones del cliente, requiere que las CA realicen cambios operativos, [45] y no proporciona tanta información como las CRL u OCSP (solo un bit por certificado para su validez); Aún se pueden utilizar CRL u OCSP para complementar Let's Revoke y proporcionar esa información adicional. [46] La implementación se puede realizar CA por CA, y los clientes se benefician del comportamiento de falla de manera 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. [45]
Las técnicas de recuperación de información privada pueden aliviar los problemas de privacidad con comprobaciones basadas en extracción. [47] En lugar de que los clientes realicen comprobaciones de revocación, un middlebox podría centralizar el coste de la comprobación de revocación y amortizarlo en muchas conexiones; los clientes no necesitan dedicar almacenamiento a la información de revocación. [48] Otra propuesta implicaba transmitir información sobre la revocación en la radio FM . [37]
{{cite journal}}: Citar diario requiere |journal=( ayuda )