¿Es posible evitar el ataque man-in-the-middle cuando se usan certificados autofirmados?

No estoy seguro de que se haya hecho una pregunta similar antes (no pude encontrar ninguna), pero ¿es posible proteger el cliente/servidor del ataque Man-In-The-Middle?¿Es posible evitar el ataque man-in-the-middle cuando se usan certificados autofirmados?

Estoy escribiendo una aplicación de cliente para comunicarme con el servidor. La comunicación estará basada en SSLv3. Estoy de acuerdo con los certificados autofirmados del servidor, pero me preocupa que alguien más genere el mismo certificado autofirmado en el mismo nombre de servidor y pretenda serlo. Mi aplicación de cliente usa la biblioteca de OpenSSL. [El cliente y el servidor están basados en el ahorro, si hace alguna diferencia]. ¿Puedo evitar tal ataque al mismo tiempo manteniendo el soporte para certificados autofirmados?

Fuente

2012-07-30 Tushar Sudake

Si su aplicación no necesita ser compatible con clientes/servidores existentes, puede ir directamente a TLS 1.x (la más alta compatible con sus bibliotecas) y omita SSL 3.0 si puede. – Bruno

@Bruno Gracias. No puedo ir por TLS por ahora. El servidor usa SSLv3. –

Sí.

En resumen, un certificado autofirmado es más inseguro que un certificado de CA solo cuando el cliente no conoce el certificado con anticipación y, por lo tanto, no tiene forma de validar que el servidor es quien dice ser.

Si agrega el certificado autofirmado al cliente y no acepta ningún otro certificado, en realidad es igual de seguro (o, podría decirse, incluso más) que tener un certificado firmado por la autoridad del certificado.

Las partes importantes para mantener SSL seguro con o sin una autoridad de certificación son;

La clave privada del servidor (y en el caso de una CA, las claves privadas de todas sus raíces) se mantiene en secreto.
El cliente conoce el certificado del servidor (o su raíz de CA).

Fuente

2012-07-30 17:10:43

Parece posible solución en mi caso. Entonces, incluso si 'man-in-the-middle' presenta el mismo certificado (clave pública para ser específico) que el de mi servidor 'real', no puede descifrar los datos del cliente ya que no tendrá el 'real' la clave privada del servidor, ¿verdad? –

@TusharSudake Exactamente, el certificado no sirve para nadie que no tenga la clave privada para ello. –

Gracias!Esto es exactamente lo que estaba buscando –

Si puede proteger sus claves privadas lo suficientemente bien, un intermediario no podrá enmascararse como usted, suponiendo que el usuario realmente mire el certificado. El problema con la autofirma es que si desea que el usuario agregue la excepción a su navegador, o simplemente ignore la advertencia, entonces estará expuesto al ataque man-in-the-middle, porque cualquier otra persona puede crear su propio certificado.

Por supuesto, "proteger sus claves privadas lo suficientemente bien" no es para nada trivial. Cuando paga por un certificado de "Verisign", no está pagando el software que crea el certificado; está pagando por las fuerzas de seguridad que custodian el edificio en el que están almacenadas las claves privadas.

Fuente

2012-07-30 17:09:15 onon15

Puede codificar el certificado del servidor y compararlo con lo que recibe.

O mejor aún, cree un certificado de CA y un certificado de servidor, firmado por la CA. Haga que la CA confíe en el cliente (nuevamente codificándola en su aplicación) y valide el certificado de servidor recibido utilizando el certificado de CA.

Fuente

2012-07-30 17:09:28

(la configuración manual también puede funcionar, en lugar de la codificación estricta). – Bruno

@Bruno de hecho. Pero esto hace que la vida y el soporte de los usuarios sean un poco más complicados, por lo que me gusta el enfoque CA hecho a sí mismo. –

¿Es posible evitar el ataque man-in-the-middle cuando se usan certificados autofirmados?

Respuesta

Cuestiones relacionadas