Certificate Transparency (CT) es un estándar abierto diseñado por Ben Laurie and Adam Langley y publicado inicialmente por la IETF en 2013, además es un framework open source de monitorización y auditado de certificados digitales. Este ecosistema compuesto principalmente de logs, monitores y auditores, permite a cualquier interesado estar informado si se emite un nuevo certificado para un determinado dominio, ayudando así a mitigar el uso de certificados fraudulentos emitidos sin el conocimiento del propietario del dominio para el que se emiten. Además, esta tecnología permite realizar un seguimiento de la actividad de las autoridades certificadoras (CAs), de modo que puedan ser detectados rápidamente en el caso por ejemplo de que hayan podido ser comprometidas con el objetivo de emitir certificados fraudulentos.
Los incidentes de seguridad registrados y problemas de privacidad relacionados con el uso de certificados fraudulentos, dejan patente la existencia de defectos en el sistema actual de certificados. Incidentes como el ocurrido con la CA holandesa DigiNotar en 2011, declarada en bancarrota tras conocerse que atacantes consiguieron emitir más de 500 certificados fraudulentos utilizando su infraestructura.
Uno de los problemas del ecosistema actual de certificados digitales, es el tiempo que transcurre hasta que un certificado fraudulento es detectado, reportado y revocado por los navegadores. Certificate Transparency pretende mitigar este problema haciendo imposible la emisión de certificados para un dominio sin el conocimiento del propietario del mismo.
Una de las principales ventajas de Certificate Transparency es que no necesita un canal alternativo para validación de los certificados, como ocurre con otras tecnologías como por ejemplo Online Certificate Status Protocol (OCSP). Así mismo, Certificate Transparency tampoco requiere de la figura de terceras partes confiables para operar.
Certificate Transparency se basa en la figura de los logs de certificados. El funcionamiento de los logs consiste en concatenar los nuevos certificados recibidos en un Árbol de Merkle.:Section 3 de hashes de solo crecimiento, es decir, los certificados del log nunca se modifican ni se borran, las únicas operaciones aceptadas son las de adición de certificados y las operaciones criptográficas necesarias para mantener la integridad del árbol. Para operar correctamente, un log debe:
Además, un log podría aceptar certificados que todavía no han sido completamente validados o incluso aquellos que han caducado.
Los monitores en Certificate Transparency, actúan como clientes de los servidores de log. Los monitores comprueban los logs en busca de certificados emitidos para un determinado dominio que se desea vigilar.
Al igual que los monitores, los auditores actúan como clientes de los servidores de log, pero en este caso comprueban la actividad del log, verificando que su funcionamiento sea correcto. De este modo, si una inconsistencia es detectada, se usa como prueba de que el log no está funcionando adecuadamente, algo que puede ser validado estudiando las firmas de la estructura del log (Árbol de Merkle).:Section 5.4
Google fue el primero en lanzar un log de Certificate Transparency, que comenzó a operar en marzo de 2013. En septiembre de ese mismo año, DigiCert fue la primera autoridad de certificación en implementar Certificate Transparency.
En 2015, Google Chrome estableció como requisito para ser aceptados por el navegador, la inclusión en Certificate Transparency para todo nuevo certificado de validación extendida emitido. Además, aplicó esta restricción a los certificados (no solo de validación extendida) emitidos por la CA Symantec desde el 1 de junio de 2016, después de conocerse que 187 certificados habían sido emitidos por esta autoridad certificadora sin el consentimiento de los propietarios de los dominios a los que iban dirigidos.
Escribe un comentario o lo que quieras sobre Certificate Transparency (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)