¿Por qué diferentes técnicas de intercambio de claves para el intercambio de claves SSL?

2

Durante el intercambio de clave ssl, he leído que enviar la clave simétrica al servidor cifrado con la clave pública del servidor es una técnica antigua. Ahora para el cambio de clave se utilizan Diffie hellman y otras técnicas.
Mi pregunta es ¿por qué el cambio de clave usando la clave pública del servidor está desactualizado? ¿Cuáles son sus deficiencias?

    
pregunta user1166690 21.04.2012 - 07:14
fuente

3 respuestas

8

La distinción no es tanto una cuestión de intercambio de claves Diffie-Hellman y RSA en general, sino que se trata de poder usar Ephemeral Diffie-Hellman, que usa el parámetro efímero (es decir, nuevo) cada vez . (También es posible usar parámetros DH fijos, pero no estoy seguro de haberlo visto nunca).

Esencialmente, si registra el tráfico cifrado y luego obtiene la clave privada del servidor, un conjunto de cifrado RSA, puede descifrar el tráfico completo de inmediato (por ejemplo, utilizando herramientas SSL de Wireshark ).

Por el contrario, al usar EDH, las nuevas claves DH aleatorias se generan (o deberían ser) cada vez que se encuentran en cada lado. Esos parámetros no se registran y no son visibles en el cable, lo que proporciona el secreto de reenvío perfecto (PFS). Esta es la razón por la que descifrar las suites de cifrado EDH no son compatibles con Wireshark. Las versiones razonablemente recientes de Wireshark pueden descifrar el tráfico que utiliza las suites de cifrado EDH, pero es necesario obtener el secreto maestro previo (cada vez) . (Consulte " Uso de la sección (Pre) -Master-Secret " de la página wiki de Wireshark SSL y esta pregunta aquí .)

(No está claro si es realmente perfecto, pero agrega otro espacio aleatorio en el que un atacante puede tener que usar fuerza bruta).

Puede encontrar más detalles en este documento de RSA Security Inc. o en al final de esta sección del Especificación TLS .

    
respondido por el Bruno 21.04.2012 - 14:57
fuente
1

Creo que no entendiste bien lo que leíste, o que obtuviste información incorrecta. Su premisa no es precisa.

Usted dijo que "el envío de la clave simétrica al servidor cifrado con la clave pública del servidor" no está actualizado. Eso no es exacto. No hay nada malo con esta forma de hacer intercambio de claves. De hecho, la mayoría de las sesiones SSL que se negocian hoy utilizan exactamente esta técnica. No hay nada obsoleto o problemático con esto.

También dijiste "Ahora, para el intercambio de claves, se utilizan Diffie Hellman y otras técnicas". Si quiso decir que Diffie-Hellman ha reemplazado el método tradicional de cifrado de la clave simétrica bajo la clave pública del servidor, tampoco es preciso. Diffie-Hellman no ha reemplazado esos métodos. El enfoque de Diffie-Hellman también es bueno y válido, pero no es exacto decir que Diffie-Hellman es algo más nuevo (de hecho, es más antiguo) o que ha reemplazado otros métodos.

    
respondido por el D.W. 23.04.2012 - 18:50
fuente
-1

Me imagino que en el centro de la misma, si no se coloca en el cable, no se puede oler y es más difícil de romper. Puedo imaginar un escenario como este: un atacante de alguna manera se interpone en medio de la comunicación entre el servidor y los clientes, y registra todos los datos. Después de un tiempo, el atacante puede comprometer el certificado del servidor, obteniendo su clave privada. Con eso, todas las sesiones SSL capturadas pueden verse comprometidas, ya que el secreto compartido puede ser descifrado.

Diffie-Hellman evita esto, ya que cada parte tiene un secreto y otra porción de datos relacionados con ese secreto que se considera público. Una vez que una parte ha recibido la pieza pública de la otra parte, se hace un poco de matemática sofisticada que genera un número que está relacionado con ambos secretos, pero que no se puede obtener de la información pública. Entonces, en resumen, el intercambio de claves DH puede ser detectado, pero no se puede obtener el secreto compartido.

En el escenario anterior, a menos que el atacante comprometa el servidor en sí e instale una versión modificada de la suite SSL que registra los secretos compartidos (una tarea mucho más complicada. Obtener el certificado completo puede implicar ingeniería social o comprometer otra caja) ), las sesiones SSL capturadas siguen siendo seguras, ya que el secreto compartido nunca se transfiere de ninguna forma.

    
respondido por el Matt Sieker 21.04.2012 - 07:21
fuente

Lea otras preguntas en las etiquetas