Hey, estudiando el protocolo SSL, me pregunto ¿cómo puede alguien hacer un ataque de repetición si falta el servidor? Todo el material que encuentro dice que los nonces lo evitan, pero no hay ejemplos que especifiquen por qué o cómo
Si el servidor usa el mismo nonce (llamado " server_random " en la especificación de SSL / TLS ) y la el mismo ID de sesión que para un protocolo de enlace anterior, luego un atacante puede enviar exactamente los mismos paquetes que los que el cliente envió durante esa sesión anterior, y el servidor aceptará todo. Al menos si el servidor utiliza un conjunto de cifrado de intercambio de claves RSA (que es el caso más común).
Esto se puede ver fácilmente siguiendo cómo se calculan los diversos elementos criptográficos. El mensaje ClientKeyExchange contiene el secreto pre-maestro, cifrado con la clave pública del servidor; ese paquete se puede reproducir y sigue siendo una versión correctamente cifrada del mismo pre-maestro-secreto. El cifrado y las claves MAC se derivan entonces del pre-master-secret, el client_random y el server_random , a través de SSL / TLS "PRF", que es determinista. Por lo tanto, si los randoms no se modifican (es decir, si el servidor usa el mismo server_random que antes, y el atacante envía el mismo mensaje ClientHello que durante la sesión anterior) y el pre-maestro-secreto tampoco cambia, entonces el el servidor inferirá las mismas claves simétricas y, por lo tanto, aceptará los paquetes cifrados capturados como auténticos.
El atacante que realiza la reproducción no obtendría ninguna información adicional sobre cómo podrían verse los datos de la aplicación; el ataque no es un ataque de descifrado . Pero desde el punto de vista del servidor, esto parecería una segunda conexión genuina y voluntaria. Para una conexión SSL utilizada para una solicitud HTTPS POST para el pago con tarjeta de crédito, esto significaría un pago doble.
Afortunadamente, se necesita incompetencia de magnitud no estándar para lograr un servidor SSL que siempre usa el mismo servidor aleatorio y la misma ID de sesión. No estoy diciendo que nunca suceda; solo que pasa raramente. En particular, la especificación TLS insiste en la idea de que los primeros cuatro bytes de client_random y server_random deberían codificar la fecha y la hora actuales, con una precisión de 1 segundo: si se cumplen, incluso con un reloj muy inclinado, esto solo asegura que un servidor con un RNG defectuoso seguirá usando un server_random distinto después de un segundo.
Lea otras preguntas en las etiquetas cryptography tls attack-prevention nonce