Certificate Transparency (CT) proporciona un mecanismo para detectar certificados emitidos de forma errónea o maliciosa por una Autoridad de Certificación (CA). Como dueño de un dominio, esto es algo que te atañe por dos motivos distintos: i) puedes detectar si un atacante está emitiendo certificados para suplantar tus sitios web; y ii) navegadores como Chrome y Safari marcan tu sitio web como «inseguro» si tu certificado no cumple con su política de CT.

¿Quieres conocer los detalles? Entonces sigue leyendo ?

El problema que aborda Certificate Transparency

El protocolo HTTPS permite comunicaciones seguras en la web. En particular, el tráfico entre el cliente (normalmente un navegador web) y el servidor está cifrado, y el sitio web puede «demostrar» que es quien dice ser. Esto último se consigue por medio de un certificado de dominio (aka certificado de servidor). Como ya sabes, este certificado consta de dos elementos principales:

• El nombre de dominio de tu sitio web. Si inspeccionas un certificado, lo encontrarás en el nombre común o el nombre alternativo del sujeto del certificado.
• La clave pública del certificado. Tu servidor web tiene acceso a la clave privada correspondiente. Cualquier otro servidor con tu clave pública pero con otra clave privada no podría suplantar tu sitio web, pues el handshake HTTPS fallaría en ese caso.

Sin embargo, estas dos piezas por sí solas no proporcionan ningún tipo de seguridad aún. ¡Yo podría emitir un certificado para tusitio.com! Por lo que tu certificado necesita un tercer elemento: debe estar firmado por una CA. La CA actúa como un tercero confiable que asegura que tu certificado es legítimo. Puesto que todas las partes confían en la CA, tu navegador aceptará el certificado de tu servidor durante el handshake HTTPS y tus usuarios pueden estar seguros de que están visitando tu sitio web…

¿Seguro? Bueno, podría no ser así. ¿Qué pasa si la CA emite a un atacante un certificado para tu sitio web por error? ¿O si la CA ha sido hackeada? Entonces tienes un problema, porque el atacante podría suplantar tu sitio web pero, desde el punto de vista de tus usuarios, parecería que están navegando por tu web de forma segura.

Umm, ¿pero esto ocurre de verdad? ¿Podria darse el caso de que una CA emita un certificado que no debería emitir? Veamos algunos ejemplos:

• Symantec emitió de forma incorrecta certificados sin el consentimiento de los dueños del dominio (incluyendo google.com y www.google.com). Además, ¡emitieron más de 2K certificados para dominios que aún no habían sido resgistrados!
• La CA DigiNotar fue hackeada y los atacantes emitieron 531 certificados maliciosos para Google, Skype, Mozilla, Microsoft, y otros dominios.
• La CA WoSign tiene una larga lista de irregularidades, incluyendo el haber emitido certificados para subdominios de GitHub sin autorización.

Ahora puede que estés pensando que, aunque un atacante obtenga un certificado para tu sitio web, aún tiene que cambiar tus registros DNS para dirigir a tus usuarios a sus servidores. Esto puede hacerse mediante ataques DNS hijacking o cache poisoning, pero ni siquiera es necesario en muchos casos. Si el atacante ya ha infectado el equipo de la víctima, p.ej. podría editar su fichero de hosts para dirigir a la víctima al sitio web malicioso. Y hay otros ataques man-in-the-middle con los que poder explotar el problema.

Dado que el problema existe y puede ser explotado, necesitamos una solución. El objetivo de CT es proporcionar mecanismos a los propietarios de dominios para detectar certificados maliciosos que se hayan emitidos para sus sitios web.

CT logs al rescate

Una solución a este problema es mantener un log abierto de todos los certificados de dominio emitidos por las CA. De esa forma, cualquier propietario de dominio puede comprobar si hay certificados que no ha solicitado. Si alguna vez eso ocurriera, el propietario puede pedirle a la CA correspondiente que revoque los certificados incorrectos.

En la práctica no hay un único CT log sino un conjunto de CT logs operados por distintas organizaciones, incluyendo Cloudflare, Comodo, DigiCert y Google. Entonces, como dueño de un dominio, ¿tienes que monitorizar todos estos logs por ti mismo para averiguar qué certificados se han emitido para tus dominios? Eso supondría una gran carga de trabajo para el propietario. Afortunadamente, existen varios servicios de monitorización de CT logs. La herramienta de Facebook para CT es gratuita y una de las más conocidas. Puedes buscar los certificados emitidos para tus dominios o subscribirte para recibir una notificación siempre que un nuevo certificado para dichos dominios se añada a un CT log.

Los CT logs no tienen mucho sentido si las CA no registran los certificados que emiten. Para incentivar a las CA a hacerlo, Google anunció que Chrome trataría cualquier web como insegura si el correspondiente certificado no estaba presente en múltiples CT logs. El resultado es que cualquier CA que quiera mantenerse en el negocio acaba registrando los certificados en CT logs – por supuesto, esto incluye a Let’s Encrypt.

El proyecto Certificate Transparency

CT comenzó como un proyecto de Google y después se convirtió es un esfuerzo colaborativo liderado por grupo de trabajo trans del IETF. Puedes encontrar la principal especificación de CT en el RFC 6962.

Política de los navegadores respecto a CT

Chrome

Puesto que la iniciativa CT se inició como un proyecto de Google, no es de extrañar que Chrome sea el navegador que haya apostado más fuerte por soportar los CT logs. Inicialmente Chrome requirió que todo certificado EV emitido después del 1 de Enero de 2015 fuera publicado en CT logs. Desde Abril de 2018, Chrome requiere que todos los certificados estén en múltiples CT logs confiables. De otra forma, tu web será tratada como «insegura» por este navegador.

Google entiende que un CT log es confiable si cumple con el RFC 6962, proporciona un uptime de (al menos) el 99%, y es capaz de añadir un nuevo certificado al log en 24 horas, entre otros requisitos.

Firefox

No he podido encontrar ningún recurso «autoritativo» de Mozilla con la política actual de Firefox, a parte de esta entrada en su wiki sobre CT que parece estar desactualizada. Según varios anuncios y algunas issues en bugzilla, Firefox soporta el RFC 6962 pero no estoy seguro de si marca de algún modo los certificados que no se han incluído en un CT log. Sin embargo, sí que he encontrado un plugin de Firefox que hace precisamente eso.

Safari

Todos los certificados para autenticación de servidor emitidos tras el 15 de Octubre de 2018 deberán cumplir con la politica de Apple sobre CT en todas sus plataformas. Esto significa que Safari no establecerá una conexión HTTPS si el certificado de dominio no ha sido publicado en un número de CT logs. El número de CT logs requerido varía en función del tiempo de validez del certificado.

IE, Edge

Aunque Microsoft apoya la iniciativa CT, parece que no están forzando su uso en ninguno de sus navegadores en el momento de escribir este artículo.

Conclusión

La iniciativa Certificate Transparency mejora la seguridad del ecosistema web permitiendo la detección de certificados de dominio duplicados (potencialmente maliciosos). Cada CA es responsable de publicar los certificados que emite en logs abiertos que pueden ser monitorizados por los propietarios de nombres de dominio, permitiendo la detección de dichos duplicados. Además, algunos navegadores alertan a los visitantes de un sitio web cuando el certificado del dominio no se ha incluído en un CT log, tratando por tanto el sitio web como si fuera inseguro.

Puesto que la mayoríaí de CAs están alineadas con esta iniciativa, no deberías tener ningún problema con tus certificados de dominio. Pero si en algún momento lo tienes, deberías dejar de usar esa CA ?

Si te ha gustado este artículo, ¡no te olvides de compartirlo! También puedes registrarte abajo si quieres que te enviemos un email cuando publiquemos nuevo material.