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.
Avances tecnológicos del siglo XXI y ejemplos de estos
Jose Torres y Sergio De Los Santos - Exploiting Certificate Transparency blind spots [rootedvlc4]
1.
2. JOSE TORRES SERGIO DE LOS SANTOS
Innovation Analyst Head of Lab
@jose7orres @ssantosv
Starring
Área de Innovación y Laboratorio
3.
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
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
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
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
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…
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?
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
SCT: - Extensión X.509v3: Incrustado en el certificado en la extensión con OID: 1.3.6.1.4.1.11129.2.4.2
- Extensión del protocolo TLS: Extensión 18 (signed_certificate_timestamp) = 0x0012 (Reconfiguración del servidor)
- Respuesta OCSP:
Comodo: Para intentar estar en el máximo numero de logs posible
Let’s Encrypt: Para probar tiempos.