protocolo de seguridad contra ataques a SSL / TLS

3

Un cliente se está comunicando con un servidor a través de https usando autenticación bidireccional. Me gustaría añadir una capa extra de seguridad.

El protocolo se vería algo así como:

  1. Una clave simétrica de 128 bits se almacena en un archivo en el servidor.

  2. El cliente se conecta a la dirección IP del servidor mediante https: // y obtiene acceso a través de su certificado de cliente en el que el servidor confía.

  3. El cliente muestra una página html vacía con un cuadro de entrada en el que tiene que escribir la clave simétrica, que luego se almacena localmente como una variable js en el navegador.

  4. Se realiza un paso de verificación al enviar un mensaje cifrado AES al servidor utilizando la clave simétrica del cliente, que luego el servidor descifra con su versión de la clave simétrica. Si esto tiene éxito, el cliente tiene acceso al resto del html.

  5. Todos los datos subsiguientes que son intercambiados por el cliente y el servidor se cifran / descifran usando la clave simétrica para AES-CBC.

Dos ejemplos de por qué esta capa adicional puede proporcionar seguridad adicional:

  • Si el atacante obtiene un certificado en el que confía el cliente y actúa como servidor. No podría leer los mensajes enviados por un cliente.
  • Si el atacante obtiene un certificado en el que confía el servidor, todavía deberá escribir la clave simétrica.

¿Tengo razón sobre los dos ejemplos y, en segundo lugar, ves algún error / ataque que desconozco?

P.S. Para aclarar: la misma clave simétrica se usaría para cada sesión, ya que es la que está fija y almacenada en el servidor. Se utiliza un IV aleatorio para cada cifrado AES-CBC y se envía junto con el mensaje cifrado.

    
pregunta peter 02.05.2017 - 17:29
fuente

3 respuestas

2

1) si alguien puede robar la clave privada TLS, ¿no puede robar la clave simétrica?

2) si alguien puede mitigar su conexión TLS, puede cambiar el javascript que el servidor envía al cliente, para que la secuencia de comandos envíe la clave ingresada por el cliente al pirata informático.

3) Si el pirata informático puede descifrar la conexión TLS y omitir la autenticación del cliente TLS, almacenará el mensaje enviado por el cliente en el paso 4, y luego volverá a conectarse al servidor y reenviará el mismo mensaje. El servidor lo descifra y otorga acceso. Para evitar esto, el servidor puede enviar algunas cadenas aleatorias (desafío) y el cliente debe enviar el desafío de nuevo encriptado y con MAC (con HMAC). Si el mensaje no está en MAC, el pirata informático puede modificar el primer bloque del mensaje cifrado en modo CBC cambiando IV y puede volver a pasar por alto la autenticación.

Parece que su solución puede hacer que sea más difícil para el pirata informático obtener su información, pero seguramente hará que sea más difícil para los usuarios legítimos trabajar con el servidor. En mi humilde opinión no mejora las cosas.

En general, crear un protocolo criptográfico robusto es una tarea muy difícil , y no se recomienda crearlo hasta que realmente sepa lo que está haciendo. Incluso los protocolos creados por grupos de profesionales al principio tienen malas vulnerabilidades.

    
respondido por el Strigo 04.05.2017 - 02:55
fuente
2

¿Dónde está la seguridad adicional en su esquema? El Cliente proporciona la clave al servidor (o atacante) para que un atacante pueda recuperarla.

Dé un paso atrás y explique contra qué ataque está tratando de defenderse. ¿Y puede explicar cómo su configuración actual para TLS no lo protege ya para esto?

Si (y supongo que su propósito aquí) estoy en lo cierto al suponer que desea agregar validación entre el cliente y el servidor. Esto se logra a través de algo llamado certificados del lado del cliente.

    
respondido por el LvB 02.05.2017 - 17:55
fuente
0

Parece que el cliente no confía en la comunicación cifrada. Dado que el conocimiento en torno a SSL / TLS es exhaustivo, quizás lo que el cliente está intentando se pueda gestionar mejor utilizando FIDO U2F.

Dicho esto, una instancia en la que un crypto adicional tiene sentido es por el contenido como el de ProtonMail que proporcionan los buzones de correo o el mega significado para ofrecer en los archivos cargados.

    
respondido por el Jean-Michel Florent 04.05.2017 - 00:58
fuente

Lea otras preguntas en las etiquetas