La pregunta que tengo es simplemente ¿cómo puedo prevenir un ataque MiTM en un certificado una vez que el servidor crea uno nuevo e intenta enviarlo a un cliente? ¿El certificado se encripta con rsa y se envía o ...
La pregunta que tengo es simplemente ¿cómo puedo prevenir un ataque MiTM en un certificado una vez que el servidor crea uno nuevo e intenta enviarlo a un cliente? ¿El certificado se encripta con rsa y se envía o ...
Tienes dos posibles ataques:
El atacante se hace pasar por un servidor falso y habla con el cliente genuino, dándole un certificado incorrecto u otros datos infames.
El atacante se hace pasar por un cliente falso y habla con el servidor original, obteniendo un certificado válido con el nombre del cliente original pero la clave del atacante.
Un ataque de hombre en el medio es cuando el atacante hace ambas cosas simultáneamente. Sin embargo, cada ataque es problemático por derecho propio.
Para vencer el primer ataque (suplantación del servidor), use los mecanismos estándar: haga que el servidor use un certificado, emitido por una CA conocida, en el que el cliente confía. Todos los sitios web de HTTPS hacen eso. Así es como, cuando te conectas a https://www.paypal.com , obtienes el ícono del candado y sabes que realmente estás hablando con el servidor de Paypal.
Para vencer el segundo ataque, bueno, depende de usted: el servidor está creando y enviando un certificado a "un cliente que acaba de conectarse". ¿Cómo sabe el servidor qué colocar en el certificado? ¿De dónde viene su conocimiento de la identidad del cliente? Si, por ejemplo, el "cliente genuino" se autentica en virtud de que se le otorgó una contraseña de registro de un solo uso, la comunicación se realizará dentro de una conexión HTTPS. En esa conexión (donde el cliente verifica el servidor como "verdadero", ver más arriba), el cliente envía su contraseña de registro de una sola vez, y el servidor, desde ese punto en adelante, sabe que está hablando con el cliente esperado. y puede enviarle un certificado o lo que desee enviarle.
Use HTTPS como sugirió Tom Leek en su respuesta. Además, solicite una contraseña al usuario y devuélvale un archivo PKCS-12 con formato cifrado que se cifra con la contraseña que recibió del usuario. El archivo PKCS-12 contendrá el certificado del usuario y la clave privada. Opcionalmente, también puede firmar el archivo PKCS-12 usando el certificado de su servidor, aunque no creo que sea necesario porque el certificado contenido dentro del archivo PKCS-12 ya está firmado por una CA válida y confiable.
Publiqué esto como una respuesta por separado porque no considero que sea suficiente enviar claves privadas a través de SSL cuando hay un procedimiento estándar conocido como PKCS-12 que se usa para proteger las claves en ciertos casos, como cuando Envíalo a través de redes no seguras. Sin embargo, si su único objetivo es derrotar un ataque MITM, la respuesta de Tom Leek puede ser suficiente. Si su objetivo es además enviar de forma segura un certificado y una clave privada, sugiero esta respuesta.
Lea otras preguntas en las etiquetas tls certificates man-in-the-middle server client