Zero Round Trip Time Resumption (0-RTT) podría ser el futuro vector de ataque para TLS 1.3
Una importante preocupación en el protocolo TSL 1.3 es el uso de un componente llamado "0-RTT" que efectivamente permite al cliente y al servidor recordar si han hablado antes y así evitar las comprobaciones de seguridad, utilizando las claves anteriores para comenzar a hablar inmediatamente.
Eso hará que las conexiones sean mucho más rápidas, pero abre un potencial agujero de seguridad que casi seguramente enfocará a aquellos que buscan explotar TLS 1.3.
El cambio fue impulsado por grandes compañías tecnológicas como Google que se beneficiarán enormemente de comunicaciones más rápidas entre sus miles de millones de conexiones, pero algunos temen que vuelva a afectar a todos. Algunas empresas no están implementando 0-RTT como resultado.
¿Cómo mejoran TLS 1.3 y 0-RTT los tiempos de conexión?
Una de las mayores ventajas de TLS 1.3 en comparación con versiones anteriores es que solo requiere un recorrido de ida y vuelta para configurar la conexión, reanudada o no.
Esto proporciona una velocidad significativa para nuevas conexiones, pero ninguna para reanudar las conexiones. Alrededor del 40% de las conexiones HTTPS.
Con 0-RTT, se pueden eliminar estos "viajes" de ida y vuelta para la mayoría de ese 40%
Reutilización de la conexión TLS por hora del día
Para resumir las diferencias de rendimiento:
TLS 1.2 (y anteriores):
- Nueva conexión: 4 RTT + DNS
- Conexión reanudada: 3 RTT + DNS
TLS 1.3:
- Nueva conexión: 3 RTT + DNS
- Conexión reanudada: 3 RTT + DNS
TLS 1.3 + 0-RTT:
- Nueva conexión: 3 RTT + DNS
- Conexión reanudada: 2 RTT + DNS
- Las ganancias de rendimiento son enormes.
¿Qué es RTT?
Round-Trip delay Time también llamado RTT. Se define como el tiempo tarda un paquete de datos enviado desde un emisor en volver a este mismo emisor habiendo pasado por el receptor de destino.
¿Cuál es el gran problema de 0-RTT?
0-RTT es tecnología de protocolo de vanguardia. Con él, las solicitudes HTTPS cifradas se vuelven tan rápidas como las solicitudes HTTP no cifradas. Este tipo de avance tiene un coste.
Este coste es que las propiedades de seguridad que TLS proporciona a la solicitud 0-RTT son ligeramente más débiles que las que proporciona a las solicitudes regulares.
Sin embargo, esta debilidad es manejable, y las aplicaciones y sitios web que siguen la semántica de HTTP no deberían tener nada de qué preocuparse. La debilidad tiene que ver con las repeticiones.
A diferencia de otras solicitudes enviadas a través de TLS, las solicitudes enviadas como parte de la reanudación de 0-RTT son vulnerables a lo que se llama un ataque de repetición.
Si un atacante tiene acceso a su conexión cifrada, puede tomar una copia de los datos cifrados de 0-RTT (que contiene su primera solicitud) y enviarla al servidor fingiendo ser tú.
Esto puede hacer que el servidor vea las solicitudes reiteradas cuando en realidad solo envió una.
Esto no suena como un gran problema hasta que considere que las solicitudes HTTP se utilizan para algo más que descargar páginas web. Por ejemplo, las solicitudes HTTP pueden desencadenar transferencias de dinero. Si alguien hace una solicitud a su banco para "pagar 1000 dólares a Juan" y esa solicitud se vuelve a realizar, Juan podría recibir pagos múltiples veces.
Afortunadamente, el ejemplo anterior es un tanto artificial. Las aplicaciones deben ser seguras para funcionar con navegadores modernos, ya sea que admitan 0-RTT o no. Los navegadores reproducen datos todo el tiempo debido a errores de red normales, y los investigadores de Google incluso han demostrado que los atacantes pueden engañar al navegador para que reproduzca las solicitudes en casi cualquier circunstancia desencadenando un tipo particular de error de red.
Las aplicaciones web bien diseñadas que manejan solicitudes delicadas utilizan mecanismos de capa de aplicación para evitar que las solicitudes repetidas les afecten.
Aunque las aplicaciones web deberían ser resistentes a la repetición, esa no siempre es la realidad.
Cómo protegerse
Para protegerse de estas aplicaciones de repeticiones maliciosas, hay que tener un enfoque extremadamente conservador para elegir qué solicitudes de 0-RTT se responderían.
Específicamente, solo las solicitudes GET sin parámetros de consulta se responden a través de 0-RTT. De acuerdo con la especificación HTTP, se supone que las solicitudes GET son idempotentes, lo que significa que no cambian el estado en el servidor y no deben usarse para cosas como la transferencia de fondos. Hay que implementar un tamaño máximo de solicitudes de 0-RTT, y limitar el tiempo para que puedan volver a reproducirse.
Otra opción sería añadir un encabezado adicional a las solicitudes 0-RTT. Este encabezado identificaría de forma única la solicitud, por lo que si se repite, el origen sabrá que se trata de un ataque de repetición.
Lo mejor que puedes hacer es como hacen algunas empresas y tener desactivado 0-RTT si tú web maneja eventos get o es una tienda online o similares. Además de aplicar las políticas de seguridad necesarias del lado del servidor.