Si un MITM tiene su clave pública y usted está haciendo SSH a través del MITM, ¿cuál es el ataque máximo que puede realizar?

Con SSH, el par de claves del servidor se usa realmente para firmas : el servidor envía una parte de los datos al cliente y lo firma . Al verificar la firma, el cliente se asegura de que la pieza de datos proviene realmente del servidor deseado. Ese "dato" contiene una clave pública Diffie-Hellman que el servidor acaba de generar, y el cliente lo utiliza para realizar el intercambio de claves criptográficas.

Para tener éxito en hacer un ataque Man-in-the-Middle , el atacante debe obtenga la clave privada de DH (pero mala suerte en eso; el servidor la conserva, y reconstruirla a partir de la contraparte pública es demasiado costoso para hacerlo con tecnología real), o alimente al cliente con una clave pública de DH falsa para la cual El atacante conoce la parte privada. Pero el cliente no aceptará una clave pública DH falsa del atacante, ya que esa falsa no se firmará con una firma correspondiente a la clave pública del servidor (la clave pública "permanente", no la DH).

Para ser breve, todos conocen la clave pública; es publico No es un problema si el atacante conoce la clave pública. Lo que sería un problema es si el cliente no conociera la clave pública del servidor, porque en ese caso el cliente no podría verificar la firma del servidor. Sin esta verificación, el atacante puede malversar al cliente con un paquete DH falso, y el ataque MitM tiene éxito.

El cliente "conoce" la clave pública del servidor al recordarla . Esta es la razón por la que la conexión first a un servidor es crítica: en ese momento, el cliente aún no conoce la verdadera clave pública del servidor. Se supone que el cliente verifica la huella dactilar de la clave al (por ejemplo) llamar al administrador del sistema.

Todo esto se basa en la magia de la criptografía asimétrica:

• Usted puede verificar una firma con la clave pública, pero la creación de nuevas firmas requiere el conocimiento de la clave privada, y la clave privada no se puede deducir (prácticamente) de la clave pública.

• El intercambio de claves DH consiste en mensajes intercambiados públicamente, el remitente y el destinatario finalmente acuerdan un "secreto compartido" obtenido al procesar estos mensajes y, sin embargo, alguien que observa solo estos mensajes no pueden volver a calcular el mismo secreto.

Las matemáticas están involucradas.

Si solo tienen su clave pública, no hay mucho que puedan hacer si se usa el cifrado, ya que no podrán comunicarse como si fueran usted.

Por eso se llama público. . . Todos pueden tener una copia de su clave pública. Todo lo que cifran con su clave pública solo puede ser descifrado por su clave privada, y viceversa.

En la criptografía asimétrica, todos tienen las claves públicas y solo la entidad verificada por la clave pública tiene la clave privada. La clave pública y la clave privada están relacionadas de manera que tener la clave pública no revela nada sobre la clave privada, pero el titular de la clave privada puede probar su identidad haciendo que alguien verifique un desafío utilizando la clave pública.

Básicamente, algo que está cifrado con una clave pública solo se puede descifrar con la clave privada y algo que se cifra con la clave privada solo se puede descifrar con la clave pública.

Para probar que el servidor es quien dicen ser, cifran un desafío con su clave privada (que solo ellos tienen) y la clave pública se usa para verificar que el desafío se puede descifrar, por lo tanto, la otra parte tiene la clave privada. llave.

Para hablar con el servidor de forma segura, la clave pública se utiliza para cifrar una clave de sesión simétrica. Esa clave de sesión se cifra con la clave pública y se envía al servidor. Solo el servidor válido (que tiene la clave privada) puede descifrar la clave de la sesión, por lo que solo el cliente (que creó la clave de la sesión) y el servidor con la clave privada pueden comunicarse.

El cliente confía en la clave pública porque está firmada de manera similar por una autoridad de certificado raíz que se incluye con el navegador.

Actualización: he leído mal la pregunta como SSL, no SSH. La idea básica sigue siendo aproximadamente la misma, pero a menudo el certificado del servidor no estará firmado por una CA, en cuyo caso el certificado debe verificarse manualmente la primera vez, luego de lo cual su cliente debe hacer un seguimiento de a quién se conectó la última vez. . El intercambio de claves también difiere en términos de cómo se acuerda una clave, pero no sé los apretones de manos de SSH tan bien como sé SSL, así que vea la respuesta de Thomas Pornin para eso.

Como es actual, hay algo más que debes considerar. MITM sin control de punto final es una cosa, y es bastante seguro (menos los debilitamientos de ciertos terroristas estatales), aún no cuenta para el MITM más efectivo, que es si tienen acceso a su servidor no cifrado, el juego finalizó. Pueden copiar la clave privada y realizar un ataque MAN-AT-THE-END en lugar del ataque MITM, que es 100% efectivo, como en el cheque MATE.