[uylug-varios] Interceptar SSL

Eduardo Trápani etrapani at gmail.com
Fri Jun 9 09:08:10 PDT 2017


> Me encantaría, de todo corazón poderte asegurar que ningún DPI se va a poder meter en tu tráfico cifrado.
[...]
>     Está toda la familia de productos que promete hacer “SSL
>     Interception”, ejemplo [1]
> [1]
> https://f5.com/solutions/deployment-guides/ssl-intercept-big-ip-v114-v120-ltm-afm

Un detalle que creo que conviene aclarar. No es que "prometan" hacerlo.
Lo digo porque sino queda una nube de duda. Simplemente lo hacen, porque
técnicamente es fácil. Y a partir de ahí, es claro que un DPI puede
tener acceso.

Pero es importante entender el cómo, porque no hay ni magia ni
heurísticas en este caso. Tampoco se trata de descifrar SSL sin más (no
hay ataques conocidos para hacer eso de manera general) sino de hacer lo
que se llama "Ataque de intermediario" o "Man in the middle"[1]. Yo lo
llamaría "man in the middle institucional".

Para interceptar SSL de manera general y global alcanza con romper la
cadena de confianza, y hacer que las máquinas de una cierta red confíen
también en el atacante (digamos el firewall). Algo simple si se
administra una red de equipos, porque se necesita derechos de
administrador para algo tan sensible. A partir de ese momento, el
atacante (que llamo firewall para simplificar) puede hacer de cuenta que
es quien quiera ser. BROU, o Google o Facebook. Tomar la identidad de
manera que en el navegador, por ejemplo, no aparezca ningún mensaje
indicando que la conexión no es segura (porque confía en el atacante).

De manera muy burda, la conexión a brou.com.uy es segura porque los
datos están cifrados y "firmados" por el Banco. ¿Cómo sabemos que están
firmados por el Banco? Porque para eso ellos usan un certificado, que
está avalado por una "cadena de confianza" en la que cree nuestra
máquina o nuestro navegador.

Como ponía en otro mensaje, esto es en principio para redes cerradas
(digamos empresariales), y la base de la implementación es trivial, no
tiene nada de vudú: se obliga a las máquinas a confiar totalmente en un
certificado que tiene el firewall. En el caso de arriba que menciona
Carlos, eso está en el manual de instalación[2]: "For this
configuration, you must have imported a certificate and key from a
Certificate Authority which are trusted by your internal clients...".

Entonces, lo que era:

usuario -> BROU

ahora es:

usuario -> Firewall (descrifra, ejecuta, cifra) -> BROU

¿Podríamos darnos cuenta como usuarios? Sí, si miráramos todos los
detalles del certificado. Pero nadie lo va a hacer y, en entornos
empresariales se puede simplemente informar que las máquinas van a a
estar haciendo eso. Más sobre esto acá[3].

¿Podría algo así hacerse fuera de un entorno cerrado donde se tiene
control de cada equipo a nivel "root"? En este momento no, a menos que
se tome control de un emisor de certificados raíz o emita certificados
falsos[4] y además se tenga control del canal para poder interceptar.
Supongo que se imaginan quiénes están en condiciones de hacer eso a
escala más o menos global...

Los que hacen los equipos también pueden incluir esos certificados.
Hasta un adware lo hacía: SuperFish[5]. Y ahí viene la pregunta, para
los softwares y aplicaciones privativos, en escritorio o teléfono o
tablets, ¿sabemos en qué certificados confían? Una razón de más para
agarrar el equipo y meterle un Linux por arriba. Un celular y ponerle
Cyanogenmod(LineageOS), etc.

Hay muchas aclaraciones que hacer. Para empezar, una cosa es interceptar
SSL. Pero hay otros cifrados. Puedo incluso diseñar uno casero. Hay
esteganografía ... Como en el resto de las cosas, todo depende de los
recursos y el interés que se pongan, tanto para atacar como para
defender. También está el hecho de que hacer MITM a nivel global,
consume muchos recursos (hay que descifrar y recifrar todas las
conversaciones).

[1] https://es.wikipedia.org/wiki/Ataque_de_intermediario
[2] http://f5.com/pdf/deployment-guides/ssl-intercept-dg.pdf
[3]
https://security.stackexchange.com/questions/12066/can-i-detect-a-mitm-attack
[4]
https://arstechnica.com/security/2015/04/google-chrome-will-banish-chinese-certificate-authority-for-breach-of-trust/
[5]
https://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/


More information about the Uylug-varios mailing list