?

Log in

No account? Create an account

July 22nd, 2018







En 2017 Google dijo que la mayor parte del tráfico de su navegador Crome ya era cifrado. Posteriormente, en un intento de aumentar estas cifras, a partir de julio del presente año, Crome también marcará como inseguras todas las páginas web que no usen https. Pero junto con el tráfico web, hay otras muchas conexiones que se están haciendo cifradas desde hace tiempo, como por ejemplo el correo electrónico. Con ello, estamos perdiendo la posibilidad de saber lo que pasa realmente en la capa de presentación del estándar OSI, que es la que soporta el SSL/TLS.

Aquí he de decir dos cosas. La primera, es que el poder acceder y explotar la información presente en todas las capas del estándar OSI, es fundamental para una defensa en profundidad de los sistemas. La segunda, es que cuanto más cerca del usuario esté la capa OSI, más información interesante podemos obtener para la seguridad, especialmente, de las capas de aplicación, de presentación, sesión y transporte.

No cabe duda de que el cifrado de todas las comunicaciones es una enorme mejora en la privacidad de los usuarios, pero también hemos de tener en cuenta, que tiene un enorme impacto en la seguridad de las organizaciones, puesto que cuando el tráfico es cifrado, los sistemas perimetrales no pueden saber si lo que entra y sale de la organización es bueno o malo, propiciando la entrada de código malicioso, o la salida de datos sensibles. Además, al perder una gran cantidad de información útil de la capa de presentación, la correlación de eventos de seguridad se hace mucho más complicada.

En esta situación, disponer de un buen "endpoint", con capacidades avanzadas como Protección Contra la Pérdida de Datos (DLP), Protección Contra la Intrusión (HIPS), filtrado de spam, antivirus con sandbox, o control de dispositivos, se convierte en una necesidad crítica para la seguridad de la organización. Es decir, que de una seguridad centrada en los perimetrales con control de la capa de aplicación, que era relativamente cómoda de gestionar, volvemos a un concepto de seguridad descentralizada basada en endpoints, que es mucho más complicada de gestionar.

Para evitar este problema, algunos fabricantes de equipos de protección de perímetro, como cortafuegos o proxies de gama media o alta, permiten la ruptura del túnel SSL/TLS. Para ello, proporcionan un hardware lo suficientemente potente, como para poder realizar, sin penalizar el tráfico, este trabajo intensivo de descifrado, análisis y posterior cifrado de las comunicaciones. Como es lógico, este incremento en la capacidad de proceso y en las funcionalidades de los equipos, se materializa en un precio sensiblemente superior al de los equipos que no permiten la ruptura del túnel. ¿Pero nos vale la pena? ¿Funciona bien esta funcionalidad?. Lo que está claro, es que hay guías de seguridad que recomiendan activar la ruptura de túnel SSL/TLS en nuestra organización, si se tiene disponible esta posibilidad.

El funcionamiento es sencillo, el dispositivo de protección de perímetro dispone de una Autoridad de Certificación (CA) integrada y a partir de ella, se generan unos certificados, que hay que instalar en todos los sitios en los que sea necesario, por ejemplo, en el almacén de certificados de los navegadores, de los clientes de correo, de máquina virtual JAVA y en el caso de Linux, en el almacén de certificados propio del sistema operativo, o de lo contrario, tendremos problemas a la hora de actualizar nuestros sistemas.

Dicho de otro modo, el sistema de ruptura de túnel SSL/TLS se comporta como un Man in the Middle (MitM), que rompe el túnel para poder analizar el tráfico entrante y saliente de nuestra organización en búsqueda de amenazas y luego lo vuelve a cifrar, para garantizar la confidencialidad de las comunicaciones.

A pesar de que todo parece sencillo, mi experiencia de campo no ha sido todo lo buena que esperaba con esta funcionalidad. Por ejemplo, a pesar de incluir el certificado en el almacén de mis sistemas Linux, he sufrido la ruptura del sistema de paquetes en varias ocasiones, por problemas de conexión a algunos repositorios. Básicamente, algunos repositorios no eran visibles para mis sistemas Linux, cuando estaba activada la ruptura del túnel SSL/TLS.

Pero el problema de fondo es mucho más grave, aún sin entrar en escabrosas consideraciones, que darían para varios artículos, relacionadas con la legislación de protección de datos y los lógicos temores por parte de los usuarios, de que su tráfico esté siendo monitorizado. Algo que permite hacer esta tecnología, tal como avisan algunos fabricantes en sus manuales.

Creo que el problema más grave es que la CA que genera el cortafuegos no es una CA de verdad, por lo que sus certificados no son "trusted" por defecto y no están en donde deben estar, es decir, con todos los certificados de las CA que sí cumplen con todos los requisitos para serlo. Por ello, estos certificados se han de instalar a mano en el área de usuario y editar su confianza también a mano, lo que crea problemas de seguridad bastante preocupantes, sobre todo, si nuestros usuarios no son muy avanzados.

Además, instalar el certificado en todos los sitios en los que debe estar, no es una tarea rápida ni sencilla. Si se nos olvida en algún sitio, habrá cosas que no funcionarán adecuadamente y cuando hablamos de actualizaciones fallidas, estamos hablando de fallos graves de seguridad y de posibles problemas de continuidad.

Veamos un problema típico tras activar la ruptura del túnel SSL/TLS. Tras instalar en el área de usuario el certificado de nuestro cortafuegos en un Android 8.0.0, tanto en la parte personal, como en la de trabajo (correspondiente a la Carpeta Segura), cada vez que nos conectemos a la WIFI del trabajo e intentemos bajar el correo corporativo desde la Carpeta Segura, nos aparecerá el siguiente mensaje, que para un usuario concienciado y debidamente formado en ciberseguridad, debe ser bastante inquietante:

"Certificado no seguro para: XXXX@XXX.es. El certificado no proviene de una entidad de confianza. Si continua con este certificado, es posible que la seguridad de sus correos electrónicos y de su cuenta se vea comprometida."

Seguido de las opciones Ver, Cancelar o Continuar.

Aquí está el problema, ante un mensaje que aparece todos los días y varias veces en el teléfono, muchos de los usuarios pulsarán directamente Continuar, sin comprobar que el certificado es el que tiene que ser, quedando claramente expuestos a un ataque de Man in the Middle (MitM), en el caso que acepten un certificado falso. Y si pulsan Ver, que es lo más seguro, la única información fiable para saber si es el certificado correcto o no, comprobar el SHA-256 del mismo, algo que es complicado de recordar y verificar cada vez que nos salta el mensaje.

Además, de vez en cuando, cuando activemos o desactivemos interfaces de comunicación y cambiemos al mismo tiempo de entorno, por ejemplo, al desactivar la WIFI y activar, los datos en el teléfono, nos aparecerá un aviso de que tenemos un certificado instalado a mano, y que eso puede afectar a la seguridad de nuestras comunicaciones.

La mejor solución, es que los fabricantes de dispositivos de seguridad perimetrales, con capacidad de ruptura del tunel SSL, se lo tomen en serio y creen CA's que cumplan con todos los requisitos necesarios, para que sus certificados puedan incluir por defecto en el área de sistema junto con los de otras CA "trusted".

Mientras que eso no ocurra, tendemos que formar y concienciar a los usuarios para que la ruptura del túnel SSL/TLS, no sea un problema más grave del que quiere evitar.

Pero también debemos considerar que también será necesario manejar excepciones. Habrá tráfico que no se podrá romper sin crear problemas, como es el caso de los servidores de actualización de algunos sistemas, o tráfico personal de los usuario a lugares "trusted", como banca, administración pública, correo personal, etc. Para ello, en lugar de listas nominales, sería mejor disponer de sistemas basados en categorías, por ejemplo: "banca online" en lugar de tener que enumerar todos los bancos y luego, si es necesario, eliminar los bancos que no se desee mediante listas negras nominales.

Pero si profundizamos más, podemos tener otros problemas de seguridad cuando activamos esta tecnología, por ejemplo:

a) "Forward proxy decryption" puede que no funcione cuando hay autenticación mutua.

c) En algunos casos, por problemas de soporte de TLS 1.2, se puede producir un downgrade a un inseguro TLS 1.1, con todo lo que ello supone para la seguridad de las comunicaciones. Recordemos que TLS 1.0 y TLS 1.1 estaban "deprecated" en enero de 2018 por sus problemas de seguridad.

d) Puede haber esquemas de cifrado no soportados, por ejemplo, AES128-GCM-SHA256 o AES256-GCM-SHA256, que forman parte de TLS 1.2.

e) Finalmente, es posible que no se puedan descifrar las sesiones en la se use un intercambio de claves Diffie-Hellman para "Forward Proxy Decryption".

En base a lo anterior, si somos unos atacantes, vemos que hay mecanismos para poner la cosas complicadas al sistema que está haciendo la ruptura del túnel SSL/TLS, ya sea para que no funcione, o para forzar un peligroso downgrade de protocolo.

Por lo tanto, creo que antes de proceder a la ruptura del túnel SSL/TLS, es conveniente realizar un análisis detallado de las ventajas e inconvenientes, incluyendo en el estudio, las posibles alternativas para paliar los problemas del cifrado en la capa de presentación, como por ejemplo, la mejora de los endpoint y la implantación de un sistema de eficaz, para facilitar la gestión de los mismos de forma centralizada.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Latest Month

July 2018
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    
Powered by LiveJournal.com
Designed by Tiffany Chow