¿Qué tan práctico / importante es el ataque Lucky Thirteen TLS?

Cuando el ataque se describió por primera vez en 2003 (el oráculo del "mal relleno" a través del análisis de tiempo), el escenario de ataque previsto era un cliente de correo electrónico (por ejemplo, Outlook Express) que se conectaba regularmente (por ejemplo, una vez por minuto) al servidor para saberlo. si ha llegado algún correo nuevo (no se le puede notificar al correo nuevo cuando se usa el protocolo POP usted tiene que votar). Dado que cada conexión comenzaría con la misma fase de autenticación, la contraseña de destino se encuentra en un emplazamiento determinista y reproducible en el flujo, y dado que Outlook Express es notoriamente malo en el informe de errores (es decir, es silencioso o simplemente actualiza un antiguo error emergente que el usuario ha sido entrenado para ignorar), entonces fue una buena configuración para el ataque.

Un punto importante que se debe hacer es que dichos ataques deben ocurrir cerca del punto descifrado , donde los "datos interesantes" (la contraseña) están a punto de ser descifrados. En el escenario del servidor de correo, esto está cerca del servidor , no del cliente.

El "Lucky Thirteen" agrega dos nuevos puntos de datos:

1. Señala que la defensa común contra los ataques de tiempo (es decir, cuando el relleno es incorrecto, actúa como si fuera bueno y, no obstante, calcular el MAC) puede perder un poco (porque el "relleno supuesto" no lo hace tener la longitud exacta del "buen relleno"). Cuando el ataque inicial de 2003 utilizó retrasos de aproximadamente 1 milisegundo, la nueva fuga es aproximadamente mil veces más corta, aproximadamente 1 microsegundo.

2. Demuestra que en condiciones de laboratorio (100 Mbits / s Ethernet con un solo interruptor entre el objetivo y el atacante, millones de medidas) son posibles medidas de hasta aproximadamente 1 microsegundo.

El primer punto es, por supuesto, interesante. Sin embargo, afirmaría que el segundo punto tiene este defecto fundamental: si el atacante puede acercarse al objetivo, entonces puede ganar de muchas otras maneras. De hecho, los ataques de tiempo tratan de extraer información de un sistema cerrado a través de fugas de datos basadas en el tiempo. Los criptógrafos tendemos a concentrarnos en la capa criptográfica, porque ese es nuestro trabajo, y la criptografía tiene que ver con la concentración de secretos : la "clave" es la esencia del secreto y un objetivo muy valioso. Sin embargo, el objetivo principal del cifrado es proteger los datos confidenciales y cualquier procesamiento de datos confidenciales puede filtrar parte de ellos a través del tiempo .

En una pila completa de procesamiento de datos, la capa SSL / TLS permanece entre la pila TCP / IP de bajo nivel y la "aplicación" que utiliza los datos confidenciales de varias maneras. Como el descifrado se produce en TLS, la capa TCP / IP solo ve fragmentos cifrados y, por lo tanto, no tiene nada que filtrar. Sin embargo, sería demasiado optimista, al borde de lo absurdo, creer que las fugas pueden ocurrir solo en la capa TLS. El código de aplicación completo es potencialmente vulnerable a los ataques de tiempo. Si bien un ataque a TLS en sí es más interesante, afirmo que los ataques al código de la aplicación son mucho más propensos a ser devastadores.

Para resumir, el ataque de los "trece afortunados" es interesante pero no muy realista. Con respecto a los ataques de tiempo, la capa TLS es solo la punta del iceberg. Abusar un poco más de la metáfora, preocuparse por los "trece afortunados" es un poco como preocuparse por la corrosión a bordo del Titanic: una preocupación válida de una manera abstracta, pero no tan apremiante como otras cuestiones relacionadas con la navegación.

Le dirijo a esta publicación de blog en particular por Matthew Green que da una buena descripción del ataque. En particular esta cita.

  

¡Pero no hay forma de que esto funcione en TLS! ¡Matará la sesión!   Recuerde que lo describí como un ataque práctico a Datagram TLS (DTLS) y más teórico a TLS. * Hay una razón para ello.

     

El motivo es que TLS (y no DTLS) incluye una contramedida más que no he mencionado todavía: cada vez que un registro no se puede descifrar (debido a un error de MAC o de relleno), el servidor TLS mata la sesión. DTLS no hace esto, lo que hace que este ataque sea práctico. (Aunque todavía se necesitan millones de consultas de paquetes para ejecutarse).

     

La característica estándar de "eliminación de sesión" de TLS parece detener los ataques de Oracle Oracle, ya que requieren que el atacante realice muchos, muchos intentos de descifrado. Matar la sesión limita al atacante a un descifrado, e intuitivamente eso parece ser el final de la misma.

     

Pero en realidad, esto no es cierto.

     

Usted ve, una de las mejores cosas de los ataques oracle de relleno es que pueden funcionar en diferentes sesiones (claves), siempre que (a) su víctima esté dispuesta a reiniciar la sesión después de que se caiga, y (b ) el texto llano secreto aparece en la misma posición en cada flujo. Afortunadamente, el diseño de los navegadores y HTTPS nos permite satisfacer ambos requisitos.   Para hacer que un navegador de destino inicie muchas conexiones, puede agregarle un Javascript personalizado que haga que se conecte repetidamente a un servidor SSL (como en el ataque de CRIME). Tenga en cuenta que el Javascript no tiene que provenir del servidor web de destino, incluso puede servir en una página no relacionada con HTTPS, posiblemente ejecutándose en una pestaña diferente. Así que en resumen: esto es bastante factible.   Además, gracias al diseño del protocolo HTTP (S), cada una de estas conexiones incluirá cookies en una ubicación conocida en el flujo HTTP. Si bien es posible que no pueda descifrar el resto de la transmisión, estos valores de cookies generalmente son todo lo que necesita para ingresar en la cuenta de alguien.   Por lo tanto, la única limitación práctica de un ataque de cookies de este tipo es el tiempo que tarda el servidor en reiniciar todas estas conexiones. Los apretones de manos TLS no son rápidos, y este ataque puede tomar decenas de miles (o millones) de conexiones por byte. Así que en la práctica, el ataque TLS probablemente tomaría días. En otras palabras: no te asustes.

     

Por otro lado, tampoco te pongas complaciente. Los autores proponen algunas optimizaciones inteligentes que podrían llevar el ataque TLS al ámbito de lo posible (para TLS) en un futuro próximo.

Usted pregunta:

  

¿Qué tan difícil sería salir de un entorno de laboratorio a una LAN conocida, o de una LAN conocida a una WAN?

Como el ataque implica medir diferencias de tiempo muy pequeñas, puede ser un poco difícil de explotar fuera de un entorno de laboratorio.

  

¿Qué tan difícil y qué tan necesario sería defenderse contra este ataque dado que no necesariamente tengo control sobre el software? ¿Existen métodos para rellenar y retrasar aleatoriamente las respuestas de HTTPS para evitar ataques de temporización?

Parece que hay poco que un usuario final pueda hacer para defenderse contra este ataque. Los administradores del sistema pueden ayudar a mitigar esto actualizando sus implementaciones SSL, cambiando al conjunto de cifrado RC4 (como medida temporal) y utilizando conjuntos de cifrado AEAD como AES-GCM.

  

¿Cómo interactúa esto con los ataques actuales contra SSL / TLS como BEAST? ¿Proporciona un efecto amplificador?

Al igual que el equipo detrás del ataque sugerido , el ataque se puede mejorar combinándolo con el estilo BEAST. técnicas.

  

¿Qué tan importante es este resultado cuando se consideran implementaciones futuras?

El ataque realmente no es nada nuevo cuando se trata de teoría, es conocimiento común de que siempre debe cifrar primero antes de aplicar el MAC.

En cuanto a la defensa, bajo Linux se podría hacer algo como esto:

  

tc qdisc agregar dev eth0 root netem delay 3ms 1ms

para agregar un retraso aleatorio a una interfaz de red como una defensa básica contra ataques de tiempo, como se menciona en presenstation Black Ops 2012 de Kaminsky .

Por supuesto, hay una compensación de rendimiento allí, pero unos pocos milisegundos son triviales en muchas situaciones.