Certificate Transparency ( CT ) es un estándar de seguridad de Internet para supervisar y auditar la emisión de certificados digitales . [1] Cuando un usuario de Internet interactúa con un sitio web, se necesita un tercero de confianza para garantizar que el sitio web sea legítimo y que la clave de cifrado del sitio web sea válida. Este tercero, llamado autoridad de certificación (CA), emitirá un certificado para el sitio web que el navegador del usuario puede validar. La seguridad del tráfico de Internet cifrado depende de la confianza de que los certificados solo los otorga la autoridad de certificación y de que esta no se haya visto comprometida.
Certificate Transparency hace públicos todos los certificados emitidos en forma de un libro de contabilidad distribuido , lo que brinda a los propietarios de sitios web y auditores la capacidad de detectar y exponer certificados emitidos de manera inapropiada.
El trabajo sobre la transparencia de los certificados comenzó en 2011, después de que la autoridad de certificación DigiNotar se viera comprometida y comenzara a emitir certificados maliciosos. Los ingenieros de Google presentaron un borrador al Grupo de trabajo de ingeniería de Internet (IETF) en 2012. Este esfuerzo dio como resultado la RFC 9162 de IETF, un estándar que define un sistema de registros públicos para registrar todos los certificados emitidos por autoridades de certificación de confianza pública , lo que permite la identificación eficiente de certificados emitidos por error o de forma maliciosa. [2]
El sistema de transparencia de certificados consiste en un sistema de registros de certificados de solo anexión . Los registros son operados por muchas partes, incluidos los proveedores de navegadores y las autoridades de certificación . [3] Los certificados que admiten la transparencia de certificados deben incluir una o más marcas de tiempo de certificado firmadas (SCT), que es una promesa de un operador de registro de incluir el certificado en su registro dentro de un retraso máximo de fusión (MMD). [4] [3] En algún momento dentro del retraso máximo de fusión, el operador de registro agrega el certificado a su registro. Cada entrada en un registro hace referencia al hash de uno anterior, formando un árbol de Merkle . La cabeza del árbol firmado (STH) hace referencia a la raíz actual del árbol de Merkle .
Aunque cualquiera puede enviar un certificado a un registro CT, esta tarea normalmente la lleva a cabo una CA de la siguiente manera: [4] [5]
Por último, una CA puede decidir registrar también el certificado final. Let's Encrypt E1 CA, por ejemplo, registra tanto los precertificados como los certificados finales (consulte la página de perfil de CA crt.sh en la sección "certificados emitidos"), mientras que Google GTS CA 2A1 no lo hace (consulte la página de perfil de crt.sh).
Algunos navegadores requieren que los certificados de seguridad de la capa de transporte (TLS) tengan prueba de estar registrados con transparencia de certificado, [7] [8] ya sea a través de SCT integrados en el certificado, una extensión durante el protocolo de enlace TLS o a través de OCSP :
Debido a la gran cantidad de certificados emitidos con la PKI web , los registros de transparencia de certificados pueden crecer hasta contener muchos certificados. Esta gran cantidad de certificados puede causar tensión en los registros. La fragmentación temporal es un método para reducir la tensión en los registros al fragmentar un registro en varios registros y hacer que cada fragmento solo acepte precertificados y certificados con una fecha de vencimiento en un período de tiempo particular (generalmente un año calendario). [13] [14] [15] La serie de registros Nimbus de Cloudflare fue la primera en utilizar la fragmentación temporal.
Uno de los problemas con la gestión de certificados digitales es que los certificados fraudulentos tardan mucho tiempo en detectarse, denunciarse y revocarse . Es posible que un certificado emitido que no se registre mediante la Transparencia de certificados nunca se detecte. La Transparencia de certificados permite que el propietario del dominio (y cualquier persona interesada) conozca cualquier certificado emitido para un dominio.
Los nombres de dominio que se utilizan en redes internas y tienen certificados emitidos por autoridades de certificación se pueden buscar públicamente a medida que sus certificados se agregan a los registros CT.
La transparencia de los certificados depende de registros de transparencia de certificados verificables. Un registro agrega nuevos certificados a un árbol de hash de Merkle en constante crecimiento . [1] : §4 Para que se considere que se comporta correctamente, un registro debe:
Un registro puede aceptar certificados que aún no sean completamente válidos y certificados que hayan expirado.
Los monitores actúan como clientes de los servidores de registros. Los monitores comprueban los registros para asegurarse de que se comportan correctamente. Se utiliza una inconsistencia para demostrar que un registro no se ha comportado correctamente y las firmas en la estructura de datos del registro (el árbol Merkle) evitan que el registro deniegue ese mal comportamiento.
Los auditores también actúan como clientes de los servidores de registros. Los auditores de Transparencia de certificados utilizan información parcial sobre un registro para verificar el registro con otra información parcial que tienen. [1] : §8.3
Apple [16] y Google [13] tienen programas de registro separados con políticas distintas y listas de registros confiables.
Los registros de transparencia de certificados mantienen sus propios almacenes raíz y solo aceptan certificados que se enlazan con las raíces de confianza. [1] Varios registros con mal funcionamiento han publicado almacenes raíz inconsistentes en el pasado. [17]
En 2011, un revendedor de la autoridad de certificación Comodo fue atacado y la autoridad de certificación DigiNotar se vio comprometida , [18] lo que demostró las fallas existentes en el ecosistema de la autoridad de certificación e impulsó el trabajo en varios mecanismos para prevenir o monitorear la emisión no autorizada de certificados. Los empleados de Google Ben Laurie , Adam Langley y Emilia Kasper comenzaron a trabajar en un marco de código abierto para detectar certificados emitidos incorrectamente el mismo año. En 2012, presentaron el primer borrador del estándar a IETF bajo el nombre en código "Sunlight". [19]
En marzo de 2013, Google lanzó su primer registro de transparencia de certificados. [20]
En junio de 2013, se publicó el RFC 6962 "Transparencia de certificados", basado en el borrador de 2012.
En septiembre de 2013, DigiCert se convirtió en la primera autoridad de certificación en implementar la Transparencia de Certificados. [21]
En 2015, Google Chrome comenzó a exigir la Transparencia de Certificados para los Certificados de Validación Extendida recién emitidos . [22] [23] Comenzó a exigir la Transparencia de Certificados para todos los certificados recién emitidos por Symantec a partir del 1 de junio de 2016, después de que se descubrió que habían emitido 187 certificados sin el conocimiento de los propietarios del dominio. [24] [25] Desde abril de 2018, este requisito se ha extendido a todos los certificados. [8]
El 23 de marzo de 2018, Cloudflare anunció su propio registro CT llamado Nimbus . [26]
En mayo de 2019, la autoridad de certificación Let's Encrypt lanzó su propio registro CT llamado Oak. Desde febrero de 2020, está incluido en las listas de registros aprobados y lo pueden usar todas las autoridades de certificación de confianza pública. [27]
En diciembre de 2021, se publicó la RFC 9162 "Certificate Transparency Version 2.0". [1] La versión 2.0 incluye cambios importantes en la estructura requerida del certificado de registro, así como compatibilidad con Ed25519 como algoritmo de firma de SCT y compatibilidad para incluir pruebas de inclusión de certificados con el SCT.
En febrero de 2022, Google publicó una actualización de su política CT, [28] que elimina el requisito de que los certificados incluyan un SCT de su propio servicio de registro CT, haciendo coincidir todos los requisitos para los certificados con los publicados previamente por Apple. [29]
En la versión 2.0 de Certificate Transparency, un registro debe utilizar uno de los algoritmos del registro de la IANA "Algoritmos de firma". [1] : 10.2.2 [30]
Ah, la transparencia de los certificados (CT). La CT resuelve el problema que acabo de describir al hacer que todos los certificados sean públicos y fáciles de auditar. Cuando las CA emiten certificados, deben enviar los certificados a al menos dos "registros públicos". Esto significa que, en conjunto, los registros contienen datos importantes sobre todos los certificados de confianza en Internet.
{{cite book}}: |work=ignorado ( ayuda )