pares de claves de usuario y problemas Man-in-the-middle

1

Estoy tratando de ver cómo intercambiar las claves de los usuarios con un servidor.

Tal vez durante el registro un applet JS genere un par de claves para el usuario. Estas claves se utilizarían para firmar solicitudes posteriores del usuario al servidor, por lo que el servidor necesita una copia de la clave pública de los usuarios para asociarse con la cuenta de ese usuario.

Pero el envío de la clave pública al servidor está sujeto a ataques MITM: si un malo lo suficientemente motivado quisiera, podría ponerse en el medio, capturar la clave pública de camino al servidor y sustituirla por una clave Él controla la clave secreta.

Parte de la solución parece ser que el agente envíe la clave pública solo a través de un canal cifrado, por ejemplo, TLS. Pero parece que con las aplicaciones basadas en el navegador, la responsabilidad sigue siendo muy importante para que el usuario sea educado y esté lo suficientemente despierto como para darse cuenta de que su sesión no es con el servidor correcto con el que debe estar conectado. En particular, nuestro chico malo motivado podría configurar algo que parezca auténtico y creíble, por ejemplo,

httpS://certificate_server_acme.com

que él tendría el control de. Nuestro usuario puede no darse cuenta de que DEBE estar conectado solo, por ejemplo, httpS://certificates.acme.com

Sospecho que esto es solo un caso de "certificados autofirmados". Las contraseñas no resuelven el problema. La verificación de la clave de un usuario por medio de un mensaje de correo electrónico no es viable, a menos que los usuarios puedan comparar y verificar una clave y nuestro malvado motivado no pueda manipular los mensajes de correo electrónico de camino al usuario.

¿O hay algo, tal vez una característica de OpenID, que pueda usarse?

    
pregunta Johan 20.03.2015 - 13:01
fuente

1 respuesta

2

Ya existe una infraestructura para administrar la confianza y se llama "Infraestructura de clave pública". Esta es la base de todos los protocolos SSL / TLS utilizados en Internet y sitios web.

La idea principal es designar un tercero de confianza (TTP) que sea reconocido por todas las partes involucradas. Estos TTP emiten su clave pública y se envían de forma predeterminada en todos los navegadores principales (debemos asumir que no hay alteraciones antes de este punto, o todo falla). Una vez que tenga esa clave pública en la que confía sin lugar a dudas, cualquier servidor puede solicitar a la TTP (que se denomina Autoridad de certificación) que les entregue un certificado. El certificado incluye una clave pública y la identidad del solicitante del certificado y del emisor del certificado. Cuando la CA verificó la identidad del solicitante, el certificado está firmado por la clave privada de la CA.

Cualquier persona que obtenga este certificado firmado puede verificar la firma de CA. Si está bien, deduce que el certificado (por lo tanto, la clave pública) pertenece a la entidad mencionada en el certificado. Luego puede usarlo para cifrar el mensaje a esta persona sin temor a que sea interceptado por otra persona.

Si alguien en el que realizar un ataque MitM en el sistema tendría que:

  • obtener un certificado falsificado para un nombre de dominio que no posee
  • haga que la víctima acepte un certificado de CA nuevo / falso sobre el que tiene el control (y luego genere un certificado falsificado)
  • romper la clave pública (muy poco probable)

De lo contrario, la firma del certificado no se verificará y, por lo tanto, no se probará la autenticidad de la clave pública.

    
respondido por el M'vy 20.03.2015 - 13:39
fuente

Lea otras preguntas en las etiquetas