Todo lo que debes saber de SSL… para migrar de una vez a TLS

Desde el año pasado con el descubrimiento de vulnerabilidades como Poodle que afectan SSL 3.0 e incluso códigos maliciosos como el troyano bancario Dyreza logran saltear SSL, quedó en evidencia que este protocolo ya no es tan seguro y por lo tanto no es garantía de seguridad en las transacciones en línea.

Todo esto seguramente ha influido en que por ejemplo el nuevo estándar PCI fuerce a la migración de SSL a TLS. Pero al final de cuentas, ¿qué es lo que hace a SSL tan vulnerable?. En este post vamos a explicar cómo funciona este protocolo, para entender cuáles son las debilidades que tiene y para de una vez por todas, tomar la decisión de migrar hacia protocolos más seguros.

SSL 101

El protocolo Secure Sockets Layer (SSL), que lleva más de veinte años en Internet, fue desarrollado para proporcionar un protocolo seguro para el intercambio de datos en una comunicación entre un servidor y un cliente. Este protocolo sirve como intermediario para establecer una comunicación segura a través de certificados, códigos de autenticación y alogritmos de cifrado. Para entender porqué este protocolo es vulnerable, es preciso entender primero las dos fases que hacen parte de su funcionamiento.La primera de ella consiste en lo que se denomina elhandshake y luego se hace el intercambio de datos.

En la primera fase, se establece la comunicación entre el cliente y el servidor, y es donde el protocolo negocia las opciones de seguridad que se van a utilizar durante la comunicación.Este proceso que ocurre en tres etapas, inicia con un mensaje de parte del cliente enviando información de la versión del protocolo soportado además de los métodos de compresión soportados y las llaves de cifrado. A este mensaje, el servidor responde entre otras cosas con la versión del protocolo, el método de compresión y el sistema de cifrado que se utilizará en la comunicación.

En la siguiente etapa se hace la autenticación y se intercambian las claves de cifrado entre ambas partes mediante el envío de los certificados, si esto no es posible se transfieren solamente las claves públicas. Con este intercambio de certificados y claves se llega a generar una clave simétrica para el intercambio de los datos. La etapa final del handshake es una notificación de la finalización del proceso, utilizando los algoritmos de cifrado establecidos al inicio del proceso.

Una vez establecidas las condiciones para el intercambio de datos, inicia la segunda etapa de la comunicación donde se hace el intercambio de datos. Como el uso del protocolo SSL se hace entre la capa de aplicación y la capa de transporte, en este intercambio de datos se añaden una serie de cabeceras para que la comunicación sea exitosa, y en donde, para cumplir con las especificaciones TCP, los paquetes que se envían no deben ser mayores a 18Kb.

De manera simplificada, durante este proceso primero se comprimen los datos y luego se agrega un código de autenticación del mensaje (MAC) para lo cual se utiliza una función de hash (MD5 o SHA-1) para finalmente cifrar todo el mensaje de acuerdo al algoritmo negociado durante el handshake y agregar las cabeceras necesarias con la información de la versión de SSL utilizada y otra información para manejar los paquetes. Con esto, los datos pasan a la capa de transporte y quedan listos para transmitirse, del otro lado el proceso inverso arranca en la capa de transporte donde se eliminan los encabezados se descifran los datos, se comprueba la MAC y si todo el proceso es satisfactorio pasa a la capa de aplicación.

Debilidades en el protocolo y los ataques posibles

A pesar que la descripción anterior no es exhaustiva, sí nos deja una idea de cómo funciona el protocolo y con la información suficiente para entender de donde vienen sus debilidades. Todos los detalles sobre el funcionamiento del protocolo se pueden encontrar en el RFC 6176.

Es importante dejar claro que el hecho de que un sitio utilice protocolo SSL, es decir que veamoshttps en su url, no es garantía de que el sitio web no sea malicioso. La explicación de esto radica en la manera en que se implementa finalmente esta comunicación. Por ejemplo si elhandshake se hace con certificados falsos, un atacante podría tener un sitio de phishing que falsifique la información de contacto sin que la víctima se percate del engaño.

Por otra parte, la implementación que se hace del protocolo también puede dejar brechas de seguridad. De hecho la vulnerabilidad Heartbleed en la implementación con OpenSSL dejaba acceder a información almacenada en la memoria del servicio permitiendo a un atacante acceder a información crítica.

Entre otras cosas se encuentra que por ejemplo los algoritmos de hash utlizados para firmar los certificados se pueden descifrar e incluso muchas veces se utilizan algoritmos de cifrado débiles por lo cual, con un ataque Man-in-the-Middle (MitM) se podría romper el cifrado y asumir la identidad de la página web.

Todas estas fallas que muchas veces se dan por la misma implementación del protocolo, han dado pie a que se desarrollen herramientas altamente efectivas que le permitirían a un atacante realizar fácilmente ataques, como SSLStrip para engañar a un usuario para que crea que está visitando un sitio seguro, cuando realmente es víctima de un ataque.

Además de que estas fallas permiten la fuga de información, también puede quedar una ventana abierta para que un atacante haga una denegación de servicio al servidor que utilice el protocolo, alterando el proceso de handshake y dejando el proceso en un ciclo abierto donde el servidor queda esperando que se resuelva el proceso mientras se siguen lanzando más peticiones falsas de inicio de sesión.

Migrar de protocolo o seguir expuestos

De los diversos escenarios posibles para un atacante que planteamos anteriormente seguramente quede la sensación que se hace necesario tomar medidas al respecto del uso de SSL como protocolo de comunicación seguro. La respuesta aparece en el protocolo sucesor, TLS, que si bien no es 100% seguro si brinda unas medidas de seguridad más robustas que SSL.

Lo importante es que todos aquellos administradores de sistemas que estén detrás de la gestión de portales que intercambien información sensible y aún siguen utilizando alguna de las versiones de SSL tomen conciencia de lo expuesto que pueden llegar a quedar su datos y lo urgente que se hace migrar a alternativas que garanticen mayores niveles de seguridad a sus usuarios.

Créditos imagen: ©FutUndBeidl /Flickr – Autor Camilo Gutiérrez Amaya, ESET

Fuente: http://www.welivesecurity.com/la-es/2015/

Fecha de consulta: 12 Junio 2015