La brecha de visibilidad de Certificate Transparency

Certificate Transparency (CT) ha tenido tanto éxito que la mayoría de la gente lo considera un componente obligatorio del ecosistema público de PKI. Probablemente se deba a que la mayoría de nosotros normalmente solo tratamos con certificados destinados a sitios web y, para esos, CT es obligatorio… en cierto modo, pero en realidad no necesariamente.

La verdad es que CT nunca llegó a formar parte de la agenda del CA/Browser Forum y no aparece en los Baseline Requirements, que es el documento principal utilizado para regular la emisión de certificados. Hay varias menciones a los precertificados (un artefacto de la implementación de CT), pero ninguna palabra sobre si las CA deberían usar CT. En teoría, y a menudo en la práctica, CT sigue siendo opcional.

Certificate Transparency es un mecanismo diseñado para imponer un nivel de control sobre lo que hacen las autoridades de certificación de confianza (CA). Estas CA se encuentran en el núcleo de la PKI web y tienen el poder de emitir certificados para cualquier propiedad en el mundo, sin ningún control técnico que las limite. Históricamente, eso ha causado muchos problemas.

CT inclina la balanza al exigir que todos los certificados emitidos se registren, es decir, se publiquen públicamente. Como parte de la emisión de certificados, las CA envían sus certificados a los registros de CT e incorporan en ellos las firmas de dichos envíos. Es fundamental que CT se aplica a nivel de los user agents, que tienen la capacidad de rechazar cualquier certificado que no cuente con suficiente prueba de registro.

¿En qué nos ayuda esto? Pues bien, obliga a los actores maliciosos a salir a la luz. Si alguien distinto de usted obtiene un certificado para una de sus propiedades, ahora puede observarlo en el flujo global de certificados públicos y reaccionar. Nadie se despierta un día y decide monitorizar el torrente de datos de CT sin más, pero existen empresas que ofrecen la monitorización como servicio (Red Sift es una de ellas).

Es fundamental contar con una monitorización activa; si no la tiene, no ocurre nada. Por ejemplo, hace un par de años, las fuerzas del orden [presuntamente] en Alemania obtuvieron un certificado para jabber.ru y lo utilizaron para interceptar tráfico XMPP. El certificado figuraba en los registros de CT, pero nadie estaba prestando atención, y la interceptación permaneció sin detectarse durante más tiempo. En otro caso, FINA, una pequeña CA de Croacia, emitió erróneamente en repetidas ocasiones certificados para la dirección IP 1.1.1.1, que pertenece a Cloudflare, sin ser detectada durante muchos meses.

En el lado positivo, incluso si no está monitorizando CT, se beneficia del efecto disuasorio, ya que los certificados emitidos erróneamente permanecen para siempre como registro público. Sus adversarios pueden no saber realmente si usted está monitorizando o no.

Ya hemos establecido que, técnicamente hablando, CT no es obligatorio. Sin embargo, resulta que algunos de los mayores consumidores de certificados sí lo exigen. Apple, Google, Microsoft y Mozilla exigen CT en distintos puntos de sus productos. En la práctica, si publica un sitio web destinado a ser consumido por un navegador, debe utilizar un certificado que se haya publicado en CT.

Pero no todos los user agents son navegadores, y en Internet hay mucho más que sitios web.

Un problema inherente a CT es que se aplica a nivel del cliente. Muchos clientes que no son conscientes de CT no ofrecen ninguna protección en absoluto. Por ello, sus adversarios pueden saltarse CT por completo, y usted no obtiene el beneficio de su protección.

Los navegadores modernos exigen CT, y también lo hacen las bibliotecas de red oficiales en las plataformas de Apple y, desde hace poco, Android. Sin embargo, existe todo un abanico de lenguajes de programación y bibliotecas TLS que no le prestan ninguna atención. Prácticamente cualquier cosa que no sea un navegador ignorará CT. Sus servidores de API, aunque hoy en día pueda estar utilizando certificados con CT, en realidad no están protegidos por CT. La comunicación entre servidores (por ejemplo, SMTP) está igualmente en riesgo. Para ciertos casos de uso, CT no aporta ningún beneficio.

A largo plazo, la única solución es que CT se incorpore a los Baseline Requirements, algo que probablemente solo ocurrirá si uno de los almacenes raíz decide exigirlo.

La situación se complica por la migración post-cuántica. Para abordar la amenaza inminente de un ordenador cuántico criptográficamente relevante, Google está trabajando en un nuevo tipo de certificado, llamado Merkle Tree Certificates (MTC). Como parte de este esfuerzo, Certificate Transparency se reconstruirá y se combinará con la emisión de certificados. Es posible que, en el futuro, contemos con dos tipos de certificados: MTC y X.509 utilizando criptografía post-cuántica. El primero contará con el beneficio de la transparencia, pero no está claro qué ocurrirá en el segundo caso.

Sin embargo, existe una manera.

A menos que usted tome alguna medida, cualquier CA puede emitir un certificado para cualquiera de sus nombres de dominio. Sin embargo, existe un mecanismo que le permite restringir la emisión por CA, e incluso por cuenta de CA. Se llama Certification Authority Authorization (CAA). CAA se puede utilizar para crear y distribuir políticas de emisión que todas las CA deben respetar. Este mecanismo no es infalible, pero su soporte es obligatorio para todas las CA.

Para cerrar la brecha de visibilidad de CT, solo necesita elegir trabajar con CA que se comprometan a registrar todos sus certificados en CT. Let's Encrypt, la CA más grande por volumen de emisión y gratuita, siempre ha registrado todo. Probablemente existan otras CA que hagan lo mismo; si no está seguro, pida a su CA una declaración oficial al respecto.

Como ejemplo de un desarrollo positivo, Amazon y DigiCert también se comprometieron recientemente a registrar todo. Sus decisiones podrían estar relacionadas con los cambios que Chrome introdujo recientemente en esta área. Según el texto de la versión 1.8 de su política raíz, el registro de precertificados es obligatorio, pero el registro de certificados sigue siendo un SHOULD.

Si desea saber más, disponemos de un whitepaper que profundiza en cómo cerrar la brecha de visibilidad de CT y utilizar CAA para afirmar el control sobre sus entornos públicos de PKI: High-Assurance Certificate Transparency Monitoring. Esta guía puede ayudarle a cerrar la brecha de visibilidad de CT, así como con otros aspectos de la seguridad de PKI, incluyendo alcanzar el santo grial de la PKI: una validación criptográfica robusta de la emisión de certificados.