Certificate Transparency

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.

Antecedentes 
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.

Ventajas 
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.

Logs en Certificate Transparency 
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.
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:
 Verificar que cada certificado o precertificado enviado, posee una cadena de certificación válida y terminada en un certificado asociado a una autoridad certificadora confiable.
 No aceptar certificados que no posean una cadena de certificación válida.
 Almacenar la totalidad de la cadena de certificación de los nuevos certificados recibidos, desde el propio certificado hasta la raíz de la cadena.
 Ofrecer esta cadena para monitorización y auditoría bajo petición.
Además, un log podría aceptar certificados que todavía no han sido completamente validados o incluso aquellos que han caducado.

Monitores en Certificate Transparency 
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.

Auditores en Certificate Transparency auditors 
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).

Implementación por parte de las autoridades de certificación 
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.

Referencias

Enlaces externos 
 RFC 6962 - Internet Engineering Task Force 
 Certificate-transparency.org, información general sobre el proyecto Certificate Transparency.
 crt.sh, un motor de consulta de certificados en los distintos logs de Certificate Tranparency.

Public key infrastructure
Seguridad en Internet
Transport Layer Security