Google ya anunció que Certificate Transparency será obligatorio en Chrome (a partir de octubre) para todos los nuevos certificados que se emitan. Esto ha forzado a todos los actores involucrados en este ecosistema (CAs, administradores de dominios, o incluso otros navegadores …) a prepararse de forma precipitada para este deadline. En esta charla detallaremos, por un lado, quién y cómo está usando Certificate Transparency realmente. A día de hoy no tenemos constancia de que se haya realizado ningún estudio a nivel global de este tipo. Por otro lado, realizaremos una profunda incursión en los puntos ciegos de la especificación de CT, con el objetivo de explotarlos, desde el punto de vista del atacante que pretende crear un “rogue certificate” y realizar un bypass de Certificate Transparency junto con las limitaciones que supone este mecanismo ante la ejecución de ataques tradicionales como por ejemplo MiTM.

2. JOSE TORRES SERGIO DE LOS SANTOS
Innovation Analyst Head of Lab
@jose7orres @ssantosv
Starring
Área de Innovación y Laboratorio

4. Certificate Transparency
• Diseñado por Google.
• Presentado y definido en el RFC 6962
• Será obligatorio en Chrome en octubre 2017
• Pretende convertirse en una de las soluciones más efectivas para
reforzar la seguridad del ecosistema TLS (HTTPS incluido)
abril 2018

5. Certificate Transparency
Existen otras aproximaciones de propósito similar:
• HPKP
• HSTS
• CAA
Aunque todas pueden funcionar de forma simultánea sin problemas
No requieren
infraestructura
adicional

6. Certificate Transparency

7. • Será adoptado por otros navegadores como Firefox.
¿Están preparados el
ecosistema TLS y el resto
de actores implicados?
Certificate Transparency
Dentro del movimiento #movingtoHTTPS que Google espera trasladar
a todo internet
Es una propuesta prometedora pero...

8. • Pretende la exposición pública de todo
nuevo certificado emitido (de cualquier tipo)
• Basado en los Árboles de Merkle
Una caja fuerte con el contenido a simple
vista!
Certificate Transparency

9. Veamos
cómo
funciona …

10. Integración en el ecosistema TLS tradicional
Certificate Transparency

11. Logs Auditors
CT
Logs
Logs Monitors
SSL Certificates
Website
Owner
Purchases
Subscribes to
Uploaded to
Verifies
their activity
Looks for
certificates
Issues
www.
Checks
Actores Implicados
Certificate Transparency
https://ct.grahamedgecombe.com/

12. Actores Implicados
¿Existe toda la infraestructura?
¿Funcionan todos los actores?
Monitores
Logs
CAs
Auditores
Certificate Transparency

13. No necesariamente…
Certificate Transparency

14. Conseguir evitar la
protección adicional que
supone CT para conseguir
ejecutar ataques típicos
como MiTM…
Objetivo

15. Necesitamos un plan …
¿Cómo evitar Certificate Transparency?

16. Necesitaremos:
• Emitir certificados asociados a un determinado
dominio sin ser descubiertos (Emulando RogueCerts)
• Estar presentes en los logs de CT y controlando en
CUÁLES queremos estar
• Pasar desapercibidos antes los monitores.
¿Cómo evitar Certificate Transparency?

17. Para ello será necesario:
¿Cómo evitar Certificate Transparency?
El diseño de la arquitectura es
bastante fiable.
Lo ideal será buscar fallos de
implementación de los
actores implicados
Evaluar los posibles problemas en el
ecosistema, detectando posibles
puntos ciegos que puedan ser
explotables

18. Almacenan y publican los certificados recopilados, sin embargo:
• No todos los logs tienen la misma cantidad de certificados.
• Igual que los navegadores, los logs solo aceptan certificados de ciertas
CAs.
• Los monitores, solo vigilan ciertos log
• Los navegadores (Chrome) solo acepta como válidos “LOG CONFIABLES”
Entonces, ¿Hay CAs discriminadas?
+ Si, las hay.
Actores implicados – CT Logs
https://www.certificate-transparency.org/known-logs https://sslmate.com/labs/ct_growth/
LOGS
CAS
MONITORES

19. Actores implicados – CT Logs

20. Actores implicados - Monitores
• Funcionan bajo demanda.
• Un usuario puede solicitar la vigilancia de
determinados dominios (no necesariamente propios)
• Prácticamente solo existen dos:
• Cert Spotter. (SSLMate)
• Facebook Certificate Transparency Monitoring tool

21. El “tiempo de
mergeo” es
especialmente
importante
Hay que tener en
cuenta el tiempo que
transcurre desde que
se emite el
certificado, hasta que
aparece en los logs

22. Podríamos ser detectados por los monitores…
¿Cómo evitarlo?

23. ¿Qué logs vigilan?
¿Cada cuánto tiempo?
¿Cuánto tardan en notificar?
Actores implicados – Monitores
¿Estos logs comparten info?

24. Sin embargo, no están
funcionando del mejor
modo…
Facebook no está
comunicando ninguna
aparición
Actores implicados – Monitores

25. Algunas están vetadas por los logs y a su vez estos en el navegador.
Podrían ayudar significativamente al ecosistema mediante dos “simples
acciones”:
• Subir el certificado a los logs inmediatamente después de emitirlos.
• Ofrecer el SCT vía OCSP o incrustado en el navegador.
Sin embargo, la mayoría no lo hace (al menos para los certificados no EV)
Actores implicados – CAs

26. Con todo lo anterior se hicieron pruebas prácticas.
• Se crearon varios dominios:
- ct-11p.com
- certransp.com
- .elevenpaths.com
• Seleccionamos varias CAs para emitir certificados:
- Comodo CA
- Let’s Encrypt
¡Manos a la obra!
(Solo aceptada en ICARUS)

27. Y por si fuera poco
Aún no hemos hablado del navegador…

28. El código fuente
Implementación en Chrome
Los logs aceptados, están ¿hardcodeados?

29. Implementación en Chrome

30. File: sth_set_component_installer.h

32. Expect-CT
Implementación en Chrome
Expect-CT: enforce;
max-age=1440;
report-URI=https://blah.com/CTReport/
enforce: El navegador espera un SCT válido o aborta la conexión
max-age: Tiempo de caché de esta directiva en el navegador (en seg.)
report-URI: URL a la que el navegador deber enviar reportes de fallos

33. Resultados
El número mínimo de log, no está definido, aunque se recomendaban 3 2
Hemos conseguido estar en 2 logs (Venafi y Digicert) con altas
posibilidades de 3 o más
- Es posible aparecer en un log pendiente de inclusión y esperar
Los logs aceptados (en Chrome), aparecen y desaparecen continuamente,
creando nuevas combinaciones por probar y posibilidades de repetir el
experimento.
https://sslmate.com/labs/ct_growth/
En julio 2017 Chrome (M60) incluyó 2 nuevos
logs de Comodo en su lista de confianza

34. ¿Más problemas?
No funciona del todo
bien en Chrome
Aún no se sabe
nada de Firefox
• ¿Y el resto de navegadores?¿MS Edge?

35. Conclusiones

36. UN ATACANTE TENDRÍA POTENCIALMENTE 40 HORAS ANTES DE SER DETECTADO
UNA VEZ DETECTADO, EL TIEMPO DE REACCIÓN, PODRÍA SER MUCHO MAYOR

37. Conclusiones
Hay que tener en cuenta que:
• CT NO se usará para revocar certificados. Solo para ayudar a detectar con
más rapidez su uso indebido.
• Una vez reportado, un certificado, deberá ser revocado mediante los
mecanismos tradicionales. Tras esto, el certificado seguirá pasando la
validación de CT para el navegador (estar en X logs)
• El conocimiento general de CT por los administradores/usuarios, es muy
bajo y su uso poco extendido (solo el 12% de certificados de Alexa están
en 3 logs)  Baja probabilidad de reporte

38. ¿Significa todo esto que CT no es una buena opción?
Todo lo contrario, es una solución muy prometedora,
pero aún debe estabilizarse.
Retrasado a ¿2018?: https://www.thesslstore.com/blog/certificate-
transparency-requirement/
Conclusiones

39. Gracias por vuestro tiempo!
¿Preguntas?