Google ya anunció que a partir de octubre de este mismo año (2017), Certificate Transparency será obligatorio en Chrome para todos aquellos certificados emitidos para dominios HTTPS. Otros navegadores, como Firefox ya han anunciado también su intención de adoptarlo en breve (aunque en ElevenPaths ya hemos desarrollado un plugin para permitir su comprobación).

Con este mecanismo, Google espera añadir una pieza más dentro de su proyecto de transparencia "Transparency Report", además de fortalecer su plan para la migración de todos sus productos y servicios a tráfico cifrado vía HTTPS. Todo esto, dentro del movimiento que ha denominado #movingtoHTTPS, que también espera trasladar a todo internet.

¿Están tanto el ecosistema TLS como el resto de actores implicados en él, preparados para la llegada de Certificate Transparency? En este informe intentamos responder a la pregunta anterior a través de un estudio del grado real de implantación de CT a día de hoy, así como con una evaluación del correcto funcionamiento de todos los componentes y actores que involucra.

Además de con alguna guía práctica, hemos contribuido en este informe con mejoras en el código del toolkit de herramientas de interactuación con los logs de Tom Ritter, mejorando algunos aspectos como la subida de certificados. Nuestro código puede encontrarse aquí.

Nivel de implantación

En Certificate Transparency, (al contrario que otros mecanismos), el nivel de adopción de la tecnología por parte de sus usuarios tiene un impacto directo sobre sobre el nivel de seguridad que aporta. En este caso en concreto, Certificate Transparency, necesita una base de certificados lo más nutrida posible, en la que idealmente los usuarios inserten todos los certificados existentes y además lo hagan lo más rápido posible.

Para evaluar el nivel de adopción de Certificate Transparency y cómo de extendido es su uso a falta de meses para su implantación "forzosa", se ha realizado un estudio basado en los dominios más populares de internet, usando como base medio millón de dominios (500264 exactamente) del TOP 1 millón de Alexa. Para todos estos dominios, se ha extraído su certificado TLS y se ha comprobado su estado en Certificate Transparency.
El resultado más significativo es que solo 64616, es decir, solo un 12.92% de los dominios estudiados implementaban Certificate Transparency. Además, de esos, solo el 87.94% realizarían correctamente la implementación, ya que el resto solo habían enviado sus dominios a menos de tres logs, algo que hará que sean detectados por el navegador como no seguros.

Dificultades para cooperar

La necesidad de cooperación entre los distintos actores es fundamental para el correcto funcionamiento de CT, pero… ¿cómo de fácil es conseguir esta colaboración?, ¿estamos ante una máquina bien engrasada?

De los 14 logs estudiados, la inmensa mayoría de autoridades certificadoras serían confiables para entre 6 y 7 de ellos y aceptarían sus certificados. Por ejemplo, el certificado de la Fábrica Nacional de Moneda y Timbre solo tiene la oportunidad de introducirse en cuatro logs. Chrome exige que se encuentre en al menos tres conocidos.
Al igual que los logs deben "confiar" en las CAs para acoger sus certificados, los usuarios de CT (CAs, propietarios de host, etc.) deben elegir a qué logs enviarán sus certificados. En este caso, hemos evaluado la popularidad de los logs en este sentido, es decir qué logs son más usados por los usuarios a la hora de subir sus certificados. Los resultados son los siguientes:
Existe una discordancia entre la popularidad de los logs más escogidos por los usuarios y el número de certificados que alberga cada log. Si bien Symantec log y Digicert Log Server se posicionan dentro de los principales en cuanto a popularidad, no ocurre lo mismo en cuanto a número de certificados, donde el terreno está prácticamente copado por Google. ¿Cómo puede ocurrir que los más populares no sean los que más certificados reciben? Tras estudiar en profundidad el ecosistema, la respuesta es "sencilla", Google se está encargando activamente de recolectar e incorporar certificados a Certificate Transparency (concretamente a sus logs), con el objetivo de nutrir el ecosistema. Sin embargo, cabe destacar dos aspectos sobre esto: Por un lado, esta recolección autónoma por parte de Google, implica que los certificados se estarían subiendo a los logs de forma totalmente transparente y desconocida para el propietario del host (algo totalmente lícito dentro del marco de CT). Por otro lado, estos certificados recolectados por Google, a día de hoy, no están contribuyendo a reforzar el ecosistema de CT, ya que aunque están en los logs, los host a los que corresponden no ofrecen el SCT correspondiente desde el servidor.

Análisis de tiempos

Además del grado de implantación de CT a nivel global y estudiar la correcta interacción entre los diferentes actores implicados, es necesario comprobar un tercer factor fundamental, el correcto funcionamiento a nivel individual de cada uno de los componentes del ecosistema. En este aspecto, destaca por ejemplo los tiempos de funcionamiento de los logs y especialmente el tiempo que transcurre desde que un certificado es emitido hasta que es incluido en un log. En base a esto, hemos obtenido los siguientes tiempos para cada log de los incluidos en Google:

Es interesante destacar además, que estos tiempos deben encontrarse dentro del MMD de cada log y que en ningún momento debe superar las 24 horas, que se consideran como límite para el correcto funcionamiento de un log. Sin embargo, en el caso de Symantec VEGA log, el tiempo medio (para las muestras estudiadas) es de 13.20 horas con un margen de más/menos 5.79 horas, por lo que el tiempo en el peor caso sería de 18.99h. Hecho que, a pesar de estar dentro del margen permitido, se acerca peligrosamente a este límite. De nuevo, recordar que hay que añadir a los tiempos anteriores una desviación adicional relativa al tiempo transcurrido entre la creación y el envío de los certificados a los logs, pero puede despreciarse debido a la baja proporción de certificados subidos por los usuarios frente a los subidos por las CA (prácticamente inmediato).

Hipotéticamente, el vector que aprovecharía un atacante, sería la ventana de tiempo desde que obtiene el SCT de los logs, hasta que el certificado es incluido en el árbol de Merkle. Este es el tiempo durante el que se posee SCT para validar ante los navegadores y sin embargo el certificado no es público o visible por los monitores. En base a esto y los resultados anteriores, hemos construido un cronograma (Figura 8) con los tiempos aproximados que se manejarían (actualmente) dentro de CT y la posibilidad de que un atacante sea detectado en función de estos tiempos.

Conclusiones

De forma más detallada, los principales problemas encontrados que afectan al funcionamiento del ecosistema, se pueden resumir en los siguientes:

• Los tiempos que se manejan en los logs: El tiempo medio desde que un certificado es emitido hasta que es recogido por los logs es demasiado alto. Esto da lugar a que un atacante pueda disponer al menos de ese tiempo para utilizar certificados fraudulentos sin que CT proteja el ecosistema.
• La inestabilidad existente en el ciclo de vida de los logs, es a su vez un reflejo de la inestabilidad en CT. Un ejemplo de esto, es que sorprendentemente, durante el desarrollo de este estudio (mayo de 2017), Let’s Encrypt ha creado y puesto en funcionamiento su propio log (aún no incluido por Google en su lista de ‘Known Logs’), para albergar sus certificados y que, llegado ya junio de 2017, cuenta con más de 27 millones de certificados. Esto, muestra la velocidad con la que se producen los acontecimientos en este ecosistema, que aún se está fraguando. De hecho, Let’s Encrypt ha manifestado en múltiples ocasiones sus quejas acerca de que ningún log de Certificate Transparency aceptara sus certificados. Finalmente, Google lanzó el log ICARUS, precisamente con este propósito.
• Dentro de la relación CA – LOG, las autoridades certificadoras deberían mostrar una mayor implicación en el ecosistema, siendo las primeras en enviar todos sus certificados emitidos a todos los posibles logs de transparencia.
• A pesar de que Google recopila una cantidad enorme de certificados en proporción a los recogidos por la vía "usual" (envío por los usuarios), estos certificados no están siendo tenidos en cuenta por Chrome porque no adjuntan su SCT. Para mejorar esto, el navegador podría revisar en los logs si el certificado se encuentra insertado aunque el host no ofrezca un SCT, lo que implicaría almacenar un registro de certificados subidos por alguno de sus medios o almacenar los propios SCT.

En resumen, Certificate Transparency está en el camino de ser una solución real y efectiva en la seguridad del ecosistema TLS/SSL, aunque a día de hoy demasiado inestable y con muchas preguntas por responder antes de poder exigir su uso obligatorio, lo que plantea la pregunta: ¿Qué ocurrirá a partir de octubre cuando CT sea obligatorio en Chrome?

En cualquier caso, parte del éxito que pueda llegar a representar este mecanismo, estará condicionado al enorme apoyo que supone contar con el impulso de Google, algo que por otro lado, revierte en su propio beneficio, principalmente aumentando la seguridad de su navegador y productos derivados.

Fuente: Blog Eleven Paths