web-dev-qa-db-fra.com

Pourquoi la réutilisation de la courbe elliptique Diffie-Hellman (ECDH) paramètre Public Server considérée comme mauvaise?

Lors de la révision de la configuration SSL/TLS à l'aide de Qualys SSL Labs, j'ai découvert que la réutilisation de la courbe elliptique Diffie-Hellman (ECDH) Public Server Param a été signalée.

Pourquoi la réutilisation de la courbe elliptique Diffie-Hellman (ECDH) paramètre Public Server considérée comme mauvaise?

encryptiontlscryptographyopenssldiffie-hellman
3
Bob Ortiz

Remarque: Je ignore délibérément la différence entre la courbe DH et elliptique ordinaire DH. Peu importe ici.

Juste une phrase médiocre.

"Param" Vs. "Paramètres Ephemeral DH" vs. "DHPARAM"

Je pense que c'est juste une phrase/terminologie médiocre. SSL Labs utilise la définition selon RFC pour vous dire essentiellement "YO, j'ai reçu le même Pubkey deux fois! Cela ne devrait pas arriver!"

SSL Labs utilise les termes DH public server param (Ys) et ECDH public server param pour ça.

Et cela n'a de sens que si vous savez qu'ils se réfèrent à la définition RFC de ce qui constitue les "paramètres" et non à la définition OpenSSL de Qu'est-ce qui compose "DHParams" .

Définition RFC

Selon le TLS 1.2 RFC, les paramètres sont définis comme suit:

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 */

Donc, ils incluent la pubkey (dh_Ys).

OpenSSL Définition

Mais cela en conflit avec OpenSSL l'utilisation des paramètres terrestres qui n'incluent pas le pubkey:

$ 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)

Seul le premier et le générateur sont inclus. Pas de pubkey.

En plus de lecture:

(Lisez une partie ci-dessous seulement si vous vous ennuyez.)

Long et Rambling Sidenote

Documentation OpenSL Sloppy.

La documentation OpenSSL pour Ephemeral DH semble avoir été contaminée par la documentation OpenSSL pour la RSA éphémères. ERSA est une chose du passé et n'est plus soutenue mais elle a fait la même chose que nous utilisons maintenant éphémère DH/ECDH.

Alors, qu'est-ce que cela a à voir avec DH/ECDH? Eh bien, la documentation pour SSL_OP_SINGLE_DH_USE lit comme ceci:

Ssl_op_single_dh_use
[.____] Créez toujours une nouvelle clé lorsque vous utilisez des paramètres temporaires/éphémères DH [...]

Mais attendez une minute! Selon la terminologie habituelle OpenSSL, la clé est la partie éphémère du paramètre/combo de clé. Alors, pourquoi utilisent-ils même un terme tel que paramètres temporaires/éphémères DH . - Eh bien, je pense qu'ils ont juste copié cela de la documentation de l'ERSA (maintenant mort et enfouie).

Donc, tandis que Cela a du sens à dire pour ERSA :

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

Il n'a pas de sens de copier cela à la documentation pour EDH :

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

Ceci est copié Verbatim de l'ancien exemple Ersa. Et dans le contexte DH, cela n'a pas de sens. Ce qui est coûteux n'est pas tellement de régénérer la clé DH mais régénérer le groupe DH.

Modifier 2017-07-23SUN: supprimé de mauvais "Vous pouvez partager votre module, aucun problème".

5
StackzOfZtuff

  • Si vous n'avez pas généré la clé vous-même, vous ne pouvez pas être sûr que ce n'est pas avec une porte arrière

  • Si une clé est partagée avec suffisamment de serveurs, il est devenu plus attrayant, plus rentable de le craquer.

2
Tom