Ataque Diffie-Hellman y MIM:   Cuando se usan variantes de algoritmos Diffie-Hellman como DHE, ECDHE, etc., en el protocolo de enlace SSL para el intercambio de claves, entonces puede ser propenso al ataque del hombre en medio (MIM).

     

Supongamos que el protocolo de enlace SSL ha comenzado y ahora es el momento del intercambio de claves, por lo que el cliente calcula su parte de clave pública de DH y la envía, ahora el malo que está sentado en el centro la intercepta y calcula su parte de clave pública de DH y envía eso. Y luego ambos computan el secreto compartido de la clave pública del otro y se establece el secreto compartido. Ahora, a pesar de que el tráfico se encripta utilizando el secreto compartido, pero como el malo hizo todo esto, podrá descifrarlo. No?

     

En el caso de RSA, ya que todo lo cifrado con clave pública solo se puede desencriptar con clave privada para que sea seguro. Estoy seguro de esto, pero con DH estoy obteniendo dudas.

Parece que estás describiendo algo como el siguiente escenario ( fuente ):

ObservequeelhombreenelcentroreemplazaelcertificadoylaclavepúblicaparaeldominiolegítimoconsupropiocertificadoyclavepúblicaantesdequeseintercambienlosparámetrosdeDH.ElMITMluegousasuclavepúblicaparafirmarlosparámetrosDH.Ahora,loquedeberíasucederesquetanprontocomoelclienterecibaelcertificado,debeverificarqueelcertificadoseemiteparaeldominioalquecreequeseestáconectando(ServidorS).CuandoselepresentauncertificadoparaundominiodiferentedelMITM(ServidorA),deberechazarloynoprocederconelintercambiodeclaves.Enunejemplomásconcreto,considerequeunclientedeseaconectarsea enlace y en lugar de obtener un certificado para el dominio google.com, obtiene un certificado para el dominio evil.com (firmado por un CA de confianza). Obviamente, el cliente no debe interpretar este certificado como válido.

  

Identidad del servidor:   Supongamos que el cifrado es TLS_ECDHE_RSA ..... Ahora, como entiendo, ECDHE es para el intercambio de claves y RSA es para demostrar la identidad o autenticación del servidor. Pero, ¿cómo se usa RSA para probar la identidad o autenticación del servidor porque se realiza con firma digital, verdad? El cliente verá que el DC del servidor está firmado por una CA de confianza e identificará y confiará en el servidor. Entonces, ¿cómo la parte "_RSA" o "ECDCA" de la suite de cifrado entra en escena para probar la identidad del servidor o para la autenticación?

     

He leído muchas explicaciones de algoritmos para el intercambio de claves, pero nunca sobre la identidad del servidor o para la autenticación de parte de la suite de cifrado "_RSA" o "ECDCA".

Sí, el certificado que presenta el MITM puede ser válido y firmado por una CA de confianza, pero el MITM no puede obtener un certificado para el Servidor S.

Tenga en cuenta que ha habido casos en los que el dominio en el certificado no se compara con el dominio al que está conectado (¡tal fue el caso en la aplicación móvil de Chase por un tiempo!), puede leer sobre tales casos en este paper , pero este es un problema de implementación, el TLS implementado correctamente no permite este escenario.

  

Pero, ¿cómo se usa RSA para probar la identidad o autenticación del servidor porque se realiza con firma digital, verdad?

Sí. Los parámetros de intercambio clave se firman con la clave a largo plazo del servidor. (Dicha clave solía ser en su mayoría RSA, pero ECDSA se está volviendo bastante común ahora).

Lectura adicional

• Consulte la sección Intercambio de claves en la respuesta de Thomas Pornin aquí: ¿Cómo funciona SSL / TLS?