Ataque de Renegociación
Una vulnerabilidad del procedimiento en el cual la renegociación fue descubierto en agosto de 2009, que puede conducir a ataques de inyección de texto plano contra SSL 3.0 y todas las versiones actuales de TLS. Por ejemplo, permite a un atacante que puede secuestrar una conexión https para empalmar sus propias peticiones en el inicio de la conversación que el cliente tiene con el servidor web. El atacante no puede realmente descifrar la comunicación cliente-servidor, por lo que es diferente de un típico ataque man-in-the-middle. Una solución a corto plazo es que los servidores de Internet dejen de permitir la renegociación, que normalmente no requerirá otros cambios a menos que se utilice la autenticación de certificados de cliente. Para corregir la vulnerabilidad, una extensión de la indicación de renegociación fue propuesta para TLS. Se requerirá que el cliente y el servidor incluyan y verifiquen información acerca de los handshake anteriores en cualquier renegociación de handshake. Esta extensión se ha convertido en una norma propuesta y se le ha asignado el número de RFC 5746. El RFC ha sido implementado por varias bibliotecas.
Ataques de reversión de Versiones
Hay modificaciones a los protocolos originales, como False Start (aprobada y habilitada por Google Chrome) o Snap Start, en las que se ha reportado que han introducido limitaciones a los ataques de reversión de versiones para TLS o para permitir que las modificaciones de la lista de conjunto de cifrado enviada por el cliente al servidor (un atacante puede ser capaz de influir en la selección de la suite de cifrado en un intento de rebajar la intensidad de juego de cifrado, ya sea para usar un algoritmo de cifrado simétrico más débil o de un intercambio de clave más débil). Se ha demostrado en la conferencia sobre seguridad informática y de comunicaciones de la Association for Computing Machinery (ACM) que la extensión False Start está en riesgo bajo ciertas circunstancias, lo que podría permitir a un atacante recuperar las claves de cifrado en línea y acceder a los datos cifrados.
Ataque BEAST
El 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una “prueba de concepto“ llamada BEAST («Browser Exploit Against SSL/TLS») usando un applet Java para violar restricciones de políticas de mismo origen, por una vulnerabilidad de CBC ampliamente conocida de TLS 1.0. Exploits prácticos de esta vulnerabilidad no se conocían, la cual fue descubierta originalmente por Phillip Rogaway en 2002.
Mozilla actualizó las versiones de desarrollo de sus librerías NSS para mitigar ataques de tipo BEAST. NSS es utilizado por Mozilla Firefox y por Google Chrome para su implementación de SSL. Algunos servidores web que tienen una implementación quebrada de la especificación SSL puede que dejen de funcionar como resultado de esto.
Microsoft emitió el boletín de seguridad MS12-006 el 12 de enero de 2012, que corrigió la vulnerabilidad BEAST al cambiar la forma en que el componente de Windows Secure Channel (SChannel) transmite los paquetes cifrados.Por su parte, Apple habilitó por defecto la protección contra BEAST en la versión OS X 10.9 Mavericks.
El ataque BEAST también se puede prevenir eliminando todos los cifrados CBC de la lista de cifrados permitidos, dejando solamente el cifrado RC4, que es ampliamente soportado por la mayoría de los sitios web.Los usuarios de Windows 7 y de Windows Server 2008 R2 pueden permitir el uso de TLS 1.1 y 1.2, pero esta contramedida fallará si no es soportado también por el otro extremo de la conexión, y caerá a TLS 1.0.
Ataques CRIME y BREACH
Los autores del ataque BEAST también son los creadores del ataque CRIME, que usa compresión de datos para adivinar. Cuando se utiliza para recuperar el contenido de la cookie de autenticación secreta, permite a un atacante realizar un secuestro de sesión en una sesión web autenticada.
Ataques de relleno
Las versiones anteriores de TLS eran vulnerables frente al ataque de relleno de oráculo descubierto en 2002. Una nueva variante, llamada Ataque Trece con suerte, fue publicada en 2013. Hasta febrero de 2013, los implementadores de TLS estaban todavía trabajando en el desarrollo de soluciones para la protección contra esta forma de ataque.
Una solución definitiva fue lanzada como la extensión Encrypt-then-MAC para TLS lanzado como RFC 7366.
Ataque POODLE
El 14 de octubre de 2014, investigadores de Google publicaron una vulnerabilidad en el diseño de SSL 3.0, lo que hace que el modo CBC de operación con SSL 3.0 sea vulnerable al ataque de relleno (CVE-2014-3566). Ellos llamaron a este ataque POODLE (en inglés, Padding Oracle On Downgraded Legacy Encryption o Relleno de oráculo en Degradación a Cifrado Obsoleto). En promedio, los atacantes sólo necesitan hacer 256 peticiones SSL 3.0 para revelar un byte de mensaje cifrado.
Aunque esta vulnerabilidad sólo existe en SSL 3.0 y la mayoría de los clientes y servidores admite TLS 1.0 y superiores, todos los principales navegadores rebajan voluntariamente a SSL 3.0 si los handshake con las nuevas versiones de TLS fallan a menos que proporcionan la opción para un usuario o administrador para deshabilitar SSL 3.0 y el usuario o el administrador lo haga. Por lo tanto, el hombre-en-el-medio primero debe llevar a cabo un ataque de rollback y luego aprovechar esta vulnerabilidad.
En general, la degradación de la seguridad elegante por el bien de la interoperabilidad es difícil llevar a cabo de una manera que no pueda ser explotada. Este es un reto especialmente en los dominios donde la fragmentación es alta.
Ataque RC4
A pesar de ataques existentes sobre RC4 que lo rompen, las suites de cifrado basadas en RC4 en SSL y TLS fueron consideradas seguros en un momento debido a la forma en que el sistema de cifrado se utilizaba en estos protocolos derrotaba a los ataques que rompían RC4, hasta que nuevos ataques divulgados en marzo de 2013 permitían que RC4 en TLS fuera quebrado completamente. En 2011 se recomendaba usar la suite RC4 como una solución alternativa para el ataque BEAST. En 2013 una vulnerabilidad fue descubierta en RC4 sugiriendo que no era una buena solución para BEAST. Un caso de un ataque fue propuesto por Alfardan, Bernstein, Paterson, Poettering y Schuldt que utilizaba nuevos sesgos estadísticos descubiertos en la tabla de clave RC4 para recuperar partes del texto en claro con un gran número de cifrados TLS. Un ataque de sesgo de doble byte en RC4 en TLS y SSL que requiere 13 × 220 cifrados para romper RC4 se dio a conocer el 8 de julio de 2013, y fue descrito como «viable» en la presentación de acompañamiento en el 22ndo Simposio USENIX de Seguridad el 15 de agosto de 2013.
Sin embargo, muchos navegadores modernos han sido diseñados para derrotar los ataques BEAST (excepto Safari para Mac OS X 10.7 o versiones anteriores, para iOS 6 o anterior, y para Windows; ver navegadores). Como resultado, RC4 ya no es la mejor opción para TLS 1.0. Los sistemas de cifrado CBC que se vieron afectados por el ataque BEAST en el pasado se están convirtiendo en una opción más popular para la protección.
Microsoft recomienda deshabilitar RC4 cuando sea posible.
Ataque de truncamiento
Ataque de truncamientoUn ataque de truncamiento TLS bloquea las peticiones de desconexión de la cuenta de la víctima para que el usuario sin saberlo, permanezca conectado a un servicio web. Cuando se envía la solicitud de fin de sesión, el atacante inyecta un mensaje TCP FIN no cifrado (no hay más datos del remitente) para cerrar la conexión. El servidor, por tanto, no recibe la solicitud de cierre de sesión y no se da cuenta de la terminación anormal.
Publicado en julio de 2013,el ataque provoca servicios web como Gmail y Hotmail que muestren una página que informa al usuario de que han salido correctamente del servicio, al tiempo que garantiza que el navegador del usuario mantiene la autorización con el servicio, lo que permite a un atacante tener el acceso para tomar el control de la cuenta que ha iniciado sesión en el usuario. El ataque no se basa en la instalación de malware en el ordenador de la víctima; los atacantes solo necesitan ponerse entre la víctima y el servidor web (por ejemplo, mediante la creación de un punto de acceso inalámbrico rebelde). Esta vulnerabilidad también requiere acceso a la computadora de la víctima.
Fallo Heartbleed
El fallo Heartbleed es una grave vulnerabilidad en la popular librería de software criptográfica OpenSSL, que afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad permite el robo de la información protegida, en condiciones normales, por el cifrado SSL / TLS que se utiliza para asegurar las cargas de datos. SSL / TLS proporciona seguridad de las comunicaciones y la privacidad a través de Internet para aplicaciones como web, correo electrónico, mensajería instantánea (IM) y algunas redes privadas virtuales (VPN).
El fallo Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves secretas utilizadas para identificar los proveedores de servicios y para cifrar el tráfico, los nombres y las contraseñas de los usuarios y el contenido real. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y de los usuarios y suplantar servicios y a los usuarios.
