¿Cómo se realizó el ataque MiTM en un certificado autofirmado mientras que nosotros mismos generamos claves privadas?

0

En MongoDB he habilitado la función SSL / TLS para cifrar la transmisión de datos entre el cliente y el servidor. Pero lo que he hecho es generar un certificado autofirmado utilizando openssl en linux.

¿La pregunta es cómo alguien puede realizar el ataque del hombre en el medio mientras yo poseo la clave privada y nadie más la tiene? ¿Por qué MiTM no se puede realizar cuando se compra a una CA?

La implementación de mi conexión MongoDB es fácil como se muestra a continuación:

pymongo.MongoClient('172.15.141.190:27017', ssl=True, ssl_crlfile='ANY_KEY.pem')

Y mongoDB config es:

net:   
    port: 27017   
    bindIp: 0.0.0.0   
    ssl:
        mode: preferSSL
        PEMKeyFile: /etc/ssl/mongodb.pem
    
pregunta ALH 01.05.2018 - 08:52
fuente

2 respuestas

3

TL; DR: el uso de certificados autofirmados no significa que MITM sea posible y el uso de un certificado emitido por una CA pública no significa que MITM sea imposible. Pero, es más probable que MITM sea posible si se usan certificados autofirmados porque los clientes que tratan con certificados autofirmados a menudo los tratan de forma incorrecta.

El uso de un certificado autofirmado no permite MITM en general y el uso de un certificado emitido por una CA pública no protege contra MITM en general. Además de mantener privada la clave privada, la protección importante contra los ataques MITM no es qué tipo de certificado se usa en el servidor, sino cómo se verifica este certificado en el cliente, es decir, si el servidor se autentica correctamente con un certificado o no.

La forma establecida de autenticar un servidor utilizando un certificado firmado por una CA pública es verificar el asunto del certificado, la cadena de confianza, el vencimiento, etc. - consulte marco de certificado SSL 101: ¿Cómo el navegador realmente verifica la validez de un certificado de servidor dado? para más detalles. Pero si un cliente no realiza estas comprobaciones o no las realiza correctamente, un atacante en la ruta podría proporcionar su propio certificado y el cliente no lo notará. En el pasado, este tipo de errores ocurrieron debido a la ignorancia o debido a errores, por ejemplo, no se verificaron los certificados, no se validó el tema, no se comprobaron las restricciones básicas, etc.

Con los certificados autofirmados, también se puede realizar la autenticación adecuada del servidor: si el cliente conoce el certificado que se espera (o su clave pública, o un hash de él ...), el cliente puede verificar que el certificado entregado coincide con el esperado. Este tipo de verificación se realiza correctamente en muchos casos de uso. Pero en muchos otros casos se hace mal: no es raro que los clientes simplemente tengan todas las comprobaciones de certificados deshabilitadas por completo si esperan un certificado autofirmado en lugar de esperar un certificado autofirmado específico. Con tales clientes rotos, MITM es fácil ya que el atacante podría usar un certificado arbitrario y el cliente lo aceptará.

    
respondido por el Steffen Ullrich 01.05.2018 - 09:11
fuente
2

Un hombre en el ataque central es posible sin el conocimiento de su clave privada al terminar la conexión con su servidor y tener una segunda conexión con el cliente.

Si esto es realmente posible, no tiene nada que ver con su clave privada, sino cómo se gestiona la confianza de la clave pública correspondiente dentro del cliente.

Aunque obtener un certificado de una CA puede mejorar la seguridad sobre "confiar en cualquier certificado autofirmado" porque se utiliza Trust Ankers de confianza, restringir la confianza en su certificado autofirmado real ofrece una seguridad aún mejor.

Sin embargo, existe la posibilidad de que haya utilizado un número primo en la generación de claves que otra persona también usó. En ese caso, su clave se obtiene fácilmente realizando aritmética simple.

    
respondido por el Tobi Nary 01.05.2018 - 09:15
fuente

Lea otras preguntas en las etiquetas