POODLE vuelve al ataque, ahora contra TLS

el

A mediados de Octubre de este mismo año, se dió a conocer el defecto que presentaba el protocolo SSLv3 que lo hacía vulnerable al ataque conocido como POODLE. Este defecto estaba asociado al tipo de cifrado que utiliza SSLv3 (RC4 y/o CBC).

Después de hacerse público el caso de POODLE y SSLv3 los especialistas Brian Smith, Bodo Moeller y Andrei Popov comenzaron a intercambiar mensajes [1], [2], [3], [4]. En la búsqueda de los efectos que podría tener dicho defecto en TLS. En uno de esos mensajes Brian le escribió a Bodo:

“Note that POODLE, or variants thereof, may apply also to TLS 1.0+ implementations. For example, back in 2010, I fixed a bug in NSS where NSS did not verify all the padding bytes in TLS 1.0 records [1]. Thus, any server that is using a version of NSS released prior to June 2010 is likely vulnerable to POODLE-like attacks even if SSL 3.0 is completely disabled. Further, note that the TLS 1.0 specification [2] does NOT say that implementations must check the padding; that requirement was only added in TLS 1.1 and TLS 1.2. Thus, an implementation could completely conform to TLS 1.0 but still vulnerable to POODLE. Finally, even though the TLS 1.1 and TLS 1.2 specifications do say that implementations must check the padding, it isn’t necessarily the case that otherwise-working implementations actually conform to that requirement, and there’s no way for the client to check that in a reliable, high-performance, and accurate way.”

El día 8 de este mes (Dic 2014) Adam Langley de Google hizo público en su blog, que este tipo de ataque también puede afectar a algunas versiones de TLS, en el cual estábamos confiando. Adam se intentó comunicar con los responsables de varias empresas para reportar el problema encontrado con POODLE y TLS, sin embargo solo obtuvo respuesta de dos de ellas (F5 y A10 Networks), las cuales ya publicaron los respectivos parches de seguridad.

De acuerdo a las investigaciones cualquier versión de TLS, que soporte métodos de cifrados antiguos (RC4, CBC y/o AEAD), es vulnerable al ataque, siempre y cuando el navegador y el servidor le den preferencia a estos métodos por encima de los métodos más fuertes (AES).

Evaluando el problema

Ivan Ristic, ya incorporó un par de pruebas a su herramienta en SSL Labs que evalúa si su servidor o navegador es vulnerable a este ataque.

Mitigando el problema

Lamentablemente, hasta el día de hoy, no hay una forma sencilla de mitigar este problema. La vía para mitigarlo es aplicando las actualizaciones correspondiente tanto a los servidores como a los navegadores, ya que no es posible desactivar las versiones más antiguas de TLS sin afectar a las versiones más recientes. Mientras tanto los desarrolladores estan trabajando para desactivar el soporte de los métodos de cifrado débiles en TLS.

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s