Prevención de MITM y repetición de ataques

6

Tengo un cliente (una aplicación móvil) y un servidor, la aplicación se conecta al servidor a través de SSL.

El servidor utiliza un certificado autofirmado y el cliente tiene un archivo (no estoy completamente seguro de qué, algo que ver con bks y la verificación del nombre de host) que valida el certificado.

Por lo que he leído, esto debería evitar los ataques MITM, en cuyo caso, aparte del acceso físico al cliente o el acceso / pirateo físico al servidor, el token de sesión es imposible de usar en un ataque de repetición.

Debido a que los usuarios no desean iniciar sesión ni una vez al mes, el token dura para siempre (a menos que se desconecte o inicie sesión en un nuevo dispositivo), solo puedo pensar en una forma de evitar esto, que es en cada solicitud se devuelve un token nuevo, pero luego un atacante podría robar la sesión de las víctimas.

Entonces, preguntas:

1) ¿Un certificado autofirmado con algún tipo de validación en el cliente (suponiendo que ninguno haya sido manipulado) protege contra ataques MITM?

2) Si no, ¿es posible evitar los ataques de reproducción con tokens de sesión persistentes o detener el secuestro si los tokens se renuevan constantemente?

No me preocupa la manipulación en el lado del cliente como datos, ya que aunque los datos de los usuarios son privados, no se pueden usar para causar más daño.

EDITAR: para aclarar, me refiero a los ataques de repetición usando los tokens de sesión, básicamente estoy tratando de averiguar si usar SSL (para evitar que los atacantes obtengan el token de sesión) es suficiente para evitar los ataques de repetición, o si necesito más validación en los tokens / clientes de sesión, y si es así, ¿qué?

    
pregunta Ray Britton 06.06.2013 - 12:08
fuente

1 respuesta

9

Los ataques Min-in-the-Middle en SSL son prevenidos por el cliente "haciendo seguro "que utiliza la clave pública del servidor correcta y genuina. Este elemento de "asegurarse" es de lo que trata la validación de certificados. Cuando el certificado del servidor es autofirmado (es decir, no es emitido por una autoridad de certificación confiable), dicha validación debe realizarse de otra manera. Un método simple, que funciona, es cuando el cliente ya conoce el certificado del servidor (está integrado en su propio código): el certificado del servidor se valida mediante una simple comparación de bit a bit. Hay muchas maneras de hacer tal validación y muchas formas de arruinarla, así que no puedo decir si su método específico es correcto o no.

Los ataques de reproducción son una bestia completamente diferente y no están relacionados con la autofirmación del certificado del servidor. Para abreviar la historia, los ataques de reproducción en SSL no funcionan, porque tanto el cliente como el servidor incluyen valores aleatorios en sus mensajes iniciales de reconocimiento (el ClientHello y el ServerHello - vea handshake overview en el estándar) y estos valores aleatorios se usan en todas las operaciones criptográficas subsiguientes, evitando la reutilización sin procesar del tráfico de red capturado previamente de qué se tratan los ataques de repetición). Los mismos datos (por ejemplo, el mismo token de sesión) se volverán a cifrar nuevamente, con una nueva clave de sesión para cada nueva conexión SSL.

    
respondido por el Thomas Pornin 06.06.2013 - 13:11
fuente

Lea otras preguntas en las etiquetas