Revocación de certificado

En la criptografía de clave pública , un certificado puede revocarse antes de que caduque, lo que indica que ya no es válido. Sin la revocación, un atacante podría explotar un 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 de certificación emisora , que produce una declaración de revocación autenticada criptográficamente .

Para distribuir información de revocación a los clientes, la puntualidad 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 en la consulta de estados de revocación y 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 fallan de manera severa y tratan un certificado como si estuviera revocado (y, por lo tanto, degradan la disponibilidad ) o fallan de manera suave y lo tratan como si no estuviera revocado (y permiten que los atacantes eludan 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 de manera suave cuando lo hagan. Las listas de revocación de certificados consumen demasiado ancho de banda para un 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 la comprobación de errores.

CUMBRE

Entorno de gestión automática de certificados

California

autoridad certificadora

TAXI

Foro de CA/Navegador

LCR

lista de revocación de certificados

CRV

vector de revocación de certificado

OCSP

Protocolo de estado de certificado en línea

PKI

infraestructura de clave pública

TLS

Seguridad de la capa de transporte

La vulnerabilidad Heartbleed , que se reveló en 2014, desencadenó una revocación masiva de certificados, ya que sus claves privadas podrían haberse filtrado. GlobalSign revocó más del 50% de los certificados emitidos. StartCom fue criticada por emitir certificados gratuitos y luego cobrar por la revocación. ^[1]

Un estudio de 2015 encontró una tasa de revocación general del 8% para los certificados utilizados en la Web, ^[2] aunque es posible que esta cifra haya 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 comprobació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 comprobación de validez y ningún navegador verificó completamente todos los certificados. ^[5] Chrome y Firefox realizan comprobaciones basadas en push para un pequeño conjunto de dominios considerados críticos. ^[6] Los navegadores muestran poco acuerdo en casos especiales en torno a la validez de los certificados, lo que puede confundir incluso a los usuarios experimentados. ^[7]

La cantidad de certificados en la PKI web 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 significativo en este crecimiento es que Let's Encrypt ofrece 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 de "notoriamente desafiante". ^[8] En 2022, la RFC 9325 caracterizó la revocación de certificados como un problema importante sin una "solución completa y eficiente". Se recomiendan OCSP y el encadenamiento de OCSP como la "base para una posible solución". ^[9]

La revocación de certificados es una "herramienta importante" para hacer frente a ataques y ataques accidentales. La RFC 9325 establece un requisito normativo para que las implementaciones de TLS tengan algún medio para desconfiar de los certificados. ^[9] Sin la revocación, un atacante puede usar un certificado comprometido para hacerse pasar por su propietario hasta su vencimiento. ^[4]

La revocación puede no ser necesaria para certificados con una duración suficientemente corta, aproximadamente del orden de horas a días, que es comparable a la duración de una respuesta OCSP. La frecuente emisión de certificados asociada normalmente requiere automatización (por ejemplo, el protocolo ACME) y puede estresar otros elementos de infraestructura (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 de un certificado (que, por ejemplo, puede saber que una clave privada ha sido comprometida) e informa a la CA. La CA luego produce y distribuye certificaciones criptográficamente autenticadas de que el certificado ha sido revocado. ^[12] Los requisitos de CA/B también permiten que una CA revoque certificados de manera autónoma si la CA es consciente de la posibilidad de una vulneración. ^[13] Cualquier persona puede presentar dicha evidencia. ^[14]

Los estados de revocación no suelen conservarse ni archivarse durante 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 la acción de una CA; ^[16] una propuesta alternativa, también basada en Transparencia de Certificados, implica que las CA envíen los CRV a los registros de CT. ^[17]

Si el estado de revocación no está disponible (lo que puede ser benigno o deberse a un ataque), un cliente se enfrenta a un dilema al evaluar un certificado: puede fallar de manera suave y asumir que el certificado aún es válido; o puede fallar de manera dura y asumir que el certificado ha sido revocado. Se trata de un equilibrio entre seguridad y disponibilidad: fallar de manera suave permite ataques de degradación , mientras que fallar de manera dura permite la denegación de servicio (debido a ataques) o provoca la 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 en línea del estado de revocación; en este caso, la falla suave no proporciona protección alguna. Los navegadores han elegido esta variante del dilema y han preferido la disponibilidad a la seguridad. ^[19]

El uso de un método de fallas severas puede introducir nuevos vectores de ataque de denegación de servicio. Por ejemplo, si los clientes esperan la implementación de OCSP y, en caso contrario, el método de fallas severas, una denegación de servicio contra los respondedores de OCSP se amplifica y se convierte en una denegación de servicio contra todos los servicios que deseen utilizar esas respuestas de OCSP. ^[10]

Existen 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 implica 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 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 en cada verificación (por ejemplo, debido al almacenamiento en caché o a recuperaciones periódicas), existe un retraso entre la revocación de un certificado y la garantía de que todos los clientes estén al tanto de la revocación. Esto presenta un equilibrio entre latencia, eficiencia y seguridad: los tiempos de caché más prolongados o las actualizaciones menos frecuentes utilizan menos recursos y reducen la latencia, pero significan que un certificado comprometido puede ser objeto de abuso 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, es decir, al distribuidor de información de revocación. ^[24]

Es conveniente 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 los 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 estado de revocación que imponga cargas pesadas a las CA puede no tener éxito, especialmente si la CA no puede obtener beneficios compensatorios de la implementación. Reducir la cantidad de partes que deben realizar cambios para adoptarla también facilita la implementación: potencialmente involucrados están las CA, los clientes, los administradores de servidores y los productores de software de servidores. La compatibilidad con versiones posteriores es un arma de doble filo, ya que los clientes y servidores antiguos no se verán afectados por un nuevo esquema, pero sus usuarios pueden no darse cuenta de que están perdiendo los beneficios de la revocación. ^[26]

Hay tres arquitecturas amplias para el acceso de los clientes 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 verificación de revocación está estrechamente integrada con el protocolo TLS y es posible que no se necesiten verificaciones separadas. ^[27]

La comprobación basada en extracción suele tener problemas de latencia y disponibilidad. Los clientes que realizan comprobaciones basadas en extracción suelen almacenar en caché las respuestas durante un breve período. Una comprobación basada puramente en extracción combinada con una verificación suave en caso de error no añade seguridad. ^[28]

La comprobación basada en push es menos eficiente en términos de ancho de banda que la comprobación basada en pull, pero gana en disponibilidad y privacidad. Se pueden utilizar diferentes métodos en cada certificado, lo que permite ajustar la compensación: tanto Google Chrome como Mozilla Firefox realizan comprobaciones basadas en push en un pequeño conjunto de certificados críticos. ^[28]

Una lista de revocación de certificados (CRL) enumera los certificados revocados. La CA emisora ​​los autentica criptográficamente. ^[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 descubrió que el certificado promedio 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 certificado en línea (OCSP) permite a los clientes preguntar de forma interactiva a un servidor (un respondedor OCSP ) sobre el estado de un certificado y recibir una respuesta autenticada criptográficamente por la CA emisora . ^[29] Fue diseñado para abordar problemas con las CRL. ^[30] Una respuesta OCSP típica es inferior a 1 kB. ^[31]

OCSP tiene problemas de escalabilidad. Depende de que el cliente tenga acceso a la red en el momento de comprobar el estado de revocación del certificado; además, el respondedor de OCSP debe ser accesible y producir respuestas utilizables, o de lo contrario la comprobación fallará y el cliente debe elegir entre fallar de manera suave o fallar de manera estricta. Muchas autoridades de certificación 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 obtener información sobre la navegación de los usuarios, lo que es un problema de privacidad . También introduce latencia en las conexiones, ya que se debe consultar al respondedor antes de que se pueda utilizar una nueva conexión. ^[18]

Un estudio de 2018 descubrió que el 1,7 % de las solicitudes a los respondedores no estaban disponibles a nivel de red y aproximadamente el 2 % adicional producía respuestas OCSP inutilizables, con una heterogeneidad significativa entre las CA y los puntos de vista del cliente. ^[32]

El engrapado OCSP es una extensión TLS que permite que las respuestas OCSP se proporcionen al cliente, junto con el certificado, al iniciar la conexión. ^[30]

El grapado de OCSP puede resolver los desafíos operativos de OCSP, es decir, las 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 para que se grape 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 una emisión adecuada; sin embargo, si un certificado puede emitirse incorrectamente sin la extensión, el grapado puede no proporcionar ninguna seguridad. ^[35]

Además de que los clientes y las CA permitan el engrapado y la extensión must-staple, los administradores de servidores también deben tomar medidas para admitir el engrapado recuperando respuestas de forma regular y luego proporcionándolas a los clientes durante el protocolo de enlace. 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 engrapado OCSP en absoluto. ^[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 comprobación de revocaciones. Sin embargo, al utilizar la Transparencia de certificados para enumerar todos los certificados vigentes, se puede producir una lista exhaustiva de falsos positivos. Esta lista se utiliza luego 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 finitos. ^[37]

CRLite permite a los clientes hacer frente a fallos de manera masiva. ^[23]

Se estimó que el estado de revocación de todos los certificados en la PKI web en enero era de 10 MB de tamaño cuando se utilizaba la cascada de filtros Bloom, con actualizaciones de 580 kB por día. En marzo de 2018, este había aumentado a 18 MB. ^[28] En una simulación con 100 millones de certificados, una tasa de vencimiento diaria 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 actualizaciones. ^[38]

Como todos los clientes recuperan la misma información, CRLite no tiene preocupaciones sobre la privacidad. ^[23]

CRLite aún no se ha implementado ampliamente. ^[9] Sin embargo, es implementable, solo requiere que un agregador recupere las CRL de las CA y luego proporcione la cascada de filtros y las actualizaciones, y para que los clientes la usen; no se necesita ninguna acción de las CA, ni tampoco de los titulares de certificados. ^[23] El agregador no necesita ser un tercero confiable : 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 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 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 ubique de manera eficiente un bit que proporciona el estado del certificado identificado dentro del CRV. Los CRV se pueden comprimir; se espera que se compriman muy bien, ya que la mayoría de los bits no estarán configurados 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 CRV se realizan por lotes, con la actualización marcada con tiempo y firmada 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 para permitir la verificación basada en push, pero los clientes más restringidos aún pueden realizar verificaciones basadas en pull, accediendo solo a CRV seleccionados o aplazando la recuperación de CRV hasta la validación del certificado. ^[43] Un cliente que usa Let's Revoke con verificación basada en push puede fallar por completo para 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 verificaciones se basan en push, entonces no hay fugas de privacidad y una vulnerabilidad reducida a la denegación de servicio o al tiempo de inactividad; sin embargo, si se usan verificaciones basadas en pull, 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. ^[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 actualizaciones. ^[44]

Let's Revoke aún no se ha implementado ampliamente. ^[9] Además de las implementaciones de los clientes, requiere que las CA realicen cambios operativos, ^[45] y no proporciona tanta información como las CRL o el OCSP (solo un bit por certificado para la validez); las CRL o el OCSP aún se pueden usar 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 resistencia a fallas de manera incremental. Debido a la eficiencia de las CRV sobre las CRL y las respuestas del OCSP, las CA pueden verse incentivadas a implementar Let's Revoke. ^[45]

Las técnicas de recuperación de información privada pueden aliviar la preocupación por la privacidad con comprobaciones basadas en extracción. ^[47] En lugar de que los clientes realicen comprobaciones de revocación, un middlebox podría, en cambio, centralizar el costo 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 de revocación en radio FM . ^[37]

• "Requisitos básicos para la emisión y gestión de certificados de confianza pública" (PDF) . CA/Browser Forum . 14 de diciembre de 2022.
• Bruhner, Carl Magnus; Linnarsson, Oscar; Nemec, Matus; Arlitt, Martin; Carlsson, Niklas (2022). "Cambio de guardia: gestión de certificados y claves públicas en Internet" (PDF) . Medición pasiva y activa . Apuntes de clase en informática. Vol. 13210. págs. 50–80. doi :10.1007/978-3-030-98785-5_3. ISBN 978-3-030-98784-8.
• Chuat, Laurent; Abdou, Abdelrahman; Sasse, Ralf; Sprenger, Christoph; Basin, David; Perrig, Adrian (2020). "SoK: Delegación y revocación, los eslabones perdidos en la cadena de confianza de la Web". Simposio europeo IEEE sobre seguridad y privacidad de 2020 (EuroS&P) . págs. 624–638. arXiv : 1906.10775 . doi :10.1109/EuroSP48549.2020.00046. ISBN . 978-1-7281-5087-1. Número de identificación del sujeto  215827701.
• Chung, Taejoong; Lok, Jay; Chandrasekaran, Balakrishnan; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Rula, John; Sullivan, Nick; Wilson, Christo (2018). "¿Está la Web preparada para el imprescindible OCSP?" (PDF) . Actas de la Conferencia de medición de Internet de 2018. págs. 105–118. doi :10.1145/3278532.3278543. ISBN . 9781450356190. Número de identificación del sujeto  53223350.
• Durumeric, Zakir; Li, Frank; Kasten, James; Amann, Johanna; Beekman, Jethro; Payer, Mathias; Weaver, Nicolas; Adrian, David; Paxson, Vern; Bailey, Michael; Halderman, J. Alex (2014). "El asunto de Heartbleed". Actas de la Conferencia de 2014 sobre medición de Internet . págs. 475–488. doi : 10.1145/2663716.2663755 . ISBN . 9781450332132.S2CID 142767  .
• Hallam-Baker, Phillip (octubre de 2015). Extensión de función de seguridad de la capa de transporte (TLS) X.509v3. doi : 10.17487/RFC7633 . RFC 7633.
• Kogan, Dmitry; Corrigan-Gibbs, Henry (agosto de 2021). "Búsquedas de listas de bloqueo privadas con lista de verificación". 30.º Simposio de seguridad de USENIX (USENIX Security 21) . Asociación USENIX . págs. 875–892. ISBN 978-1-939133-24-3.
• Korzhitskii, Nikita; Carlsson, Niklas (2021). "Estados de revocación en Internet". Medición pasiva y activa . Apuntes de clase en informática. Vol. 12671. págs. 175–191. arXiv : 2102.04288 . doi :10.1007/978-3-030-72582-2_11. ISBN 978-3-030-72581-5. Número de identificación del sujeto  231846906.
• Korzhitskii, Nikita; Nemec, Matus; Carlsson, Niklas (2022). “Postcertificados de Transparencia de Revocación”. arXiv : 2203.02280 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). "CRLite: un sistema escalable para enviar todas las revocaciones de TLS a todos los navegadores". Simposio IEEE sobre seguridad y privacidad de 2017 (SP) . págs. 539–556. doi : 10.1109/sp.2017.17 . ISBN . 978-1-5090-5533-3. Número de identificación del sujeto  3926509.
• Leibowitz, Hemi; Ghalwash, Haitham; Syta, Ewa; Herzberg, Amir (2021). "CTng: Certificado seguro y transparencia de revocación". Archivo de ePrints de criptología .
• Liu, Yabing; Tome, Will; Zhang, Liang; Choffnes, David; Levin, Dave; Maggs, Bruce; Mislove, Alan; Schulman, Aaron; Wilson, Christo (2015). "Una medición de extremo a extremo de la revocación de certificados en la PKI de la Web". Actas de la Conferencia de medición de Internet de 2015. págs. 183–196. doi : 10.1145/2815675.2815685 . ISBN . 9781450338486.S2CID 1955346  .
• Prince, Matthew (17 de abril de 2014). "Los costos ocultos de Heartbleed". El blog de Cloudflare . Cloudflare .
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (noviembre de 2022). Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS). doi : 10.17487/RFC9325 . RFC 9325.
• Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). "Let's Revoke: Scalable Global Certificate Revocation". Actas del Simposio sobre seguridad de redes y sistemas distribuidos de 2020. doi : 10.14722 /ndss.2020.24084 . ISBN . 978-1-891562-61-7.S2CID211268930  .​
• Szalachowski, Pawel; Chuat, Laurent; Lee, Taeho; Perrig, Adrian (2016). "RITM: Revocación en el medio". 2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS) . págs. 189–200. arXiv : 1604.08490 . doi :10.1109/ICDCS.2016.91. ISBN 978-1-5090-1483-5.S2CID 761560  .
• Wazan, AS; Laborde, R.; Chadwick, DW; Barrere, F.; Benzekri, A. (11 de septiembre de 2017). "Validación de conexión TLS por parte de navegadores web: ¿por qué los navegadores web aún no están de acuerdo?". 2017 IEEE 41st Annual Computer Software and Applications Conference (COMPSAC) . págs. 665–674. doi :10.1109/COMPSAC.2017.240. ISBN . 9781538603673.S2CID28599113  .​