¿Por qué la reutilización del servidor público de curva elíptica Diffie-Hellman (ECDH) se considera mala?

3

Al revisar la configuración de SSL / TLS con Qualys SSL Labs, descubrí que la reutilización del parámetro del servidor público de curva elíptica Diffie-Hellman (ECDH) estaba marcada.

¿Por qué la reutilización del parámetro de servidor público de curva elíptica Diffie-Hellman (ECDH) se considera incorrecta?

    
pregunta Bob Ortiz 17.07.2017 - 19:54
fuente

2 respuestas

4

Nota: estoy ignorando deliberadamente la diferencia entre DH regular y curva elíptica DH. No importa aquí.

Solo frases incorrectas.

"public server param" frente a "Ephemeral DH parameters" vs. "dhparam"

Creo que esto es solo una mala frase / terminología. SSL Labs usa la definición según RFC para básicamente decirle "¡Yo, recibí la misma clave de acceso dos veces! ¡Esto no debería suceder!"

SSL Labs usa los términos DH public server param (Ys) y ECDH public server param para esto.

Y esto solo tiene sentido si sabes que se están refiriendo a la definición RFC de lo que compone los "parámetros" y no a la definición openssl de lo que compone "dhparams ".

definición de RFC

Según el RFC de TLS 1.2, los parámetros se definen así:

struct {
    opaque dh_p<1..2^16-1>;
    opaque dh_g<1..2^16-1>;
    opaque dh_Ys<1..2^16-1>;
} ServerDHParams;     /* Ephemeral DH parameters */

Para que INCLUYAN la clave de acceso ( dh_Ys ).

Definición de OpenSSL

Pero esto entra en conflicto con el uso de OpenSSL del término params que NO incluye la clave de acceso:

$ openssl dhparam 123 -noout -text
Generating DH parameters, 123 bit long safe prime, generator 2
This is going to take a long time
......+..++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*
    DH Parameters: (123 bit)
        prime:
            04:f4:19:58:a6:2c:ad:1f:4f:b8:a9:b9:fd:3d:ea:
            1b
        generator: 2 (0x2)

Solo se incluyen el prime y el generador. No PubKey.

Lectura adicional:

(Lea la parte inferior solo si está aburrido).

Sidenote largo y divagante

Documentación Sloppy openssl.

La documentación de openssl para DH efímero parece haber sido contaminada por la documentación de openssl para RSA efímero. eRSA es una cosa del pasado y ya no se admite, pero hizo lo mismo que ahora usamos para DH / ECDH efímero.

Entonces, ¿qué tiene eso que ver con DH / ECDH? Bueno, la documentación para SSL_OP_SINGLE_DH_USE se lee así:

  

SSL_OP_SINGLE_DH_USE
  Siempre cree una nueva clave cuando use parámetros DH temporales / efímeros [...]

Pero espera un minuto! De acuerdo con la terminología habitual de openssl, KEY es la parte efímera del combo de parámetros / teclas. Entonces, ¿por qué incluso usan un término como parámetros temporales / efímeros de DH . - Bueno, creo que simplemente copiaron eso de la documentación de la eRSA (ahora muerta y enterrada).

Entonces, mientras ESTO tiene sentido decirlo para eRSA :

/* Generating a key on the fly is very costly, so use what is there */
if (rsa_1024)
    rsa_tmp=rsa_1024;

NO tiene sentido copiar eso en la documentación para eDH :

/* Generating a key on the fly is very costly, so use what is there */
setup_dh_parameters_like_above();

Esto se copia textualmente del antiguo ejemplo de eRSA. Y en el contexto de DH, esto NO tiene sentido. Lo que es costoso no es tanto regenerar la CLAVE DH, sino regenerar el GRUPO DH.

Editar 2017-07-23Sun: Eliminado incorrectamente "puedes compartir tu módulo, no hay problema".

    
respondido por el StackzOfZtuff 18.07.2017 - 15:58
fuente
1
  • Si no generó la clave por sí mismo, no puede estar seguro de que no esté con una puerta trasera

  • Si una clave se comparte con suficientes servidores, se vuelve más atractiva y más rentable para descifrarla.

respondido por el Tom 18.07.2017 - 12:34
fuente

Lea otras preguntas en las etiquetas