Nota: sto deliberatamente ignorando la differenza tra DH normale e curva ellittica DH. Non importa qui.

Pessimo fraseggio.

"param server pubblico" vs "Parametri DH effimeri" vs. "dhparam"

Penso che questo sia solo un fraseggio / terminologia scadente. SSL Labs usa la definizione come da RFC per dirti essenzialmente "Yo, ho ricevuto lo stesso pubkey due volte! Questo non dovrebbe succedere!"

Labs SSL utilizza i termini DH public server param (Ys) e ECDH public server param per questo.

E questo ha senso solo se si sa che si riferiscono alla definizione RFC di ciò che costituisce i "parametri" e non alla definizione openssl di ciò che costituisce "dhparams ".

Definizione RFC

Come per TLS 1.2 RFC i parametri sono definiti in questo modo:

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

Quindi FANNO INCLUDERE il pubkey ( dh_Ys ).

Definizione OpenSSL

Ma questo è in conflitto con l'uso di OpenSSL del termine params che NON include il 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)

Solo il primo e il generatore sono inclusi. Nessun PubKey.

Ulteriori letture:

• Una risposta precedente della mia .

(Leggi la parte sotto solo se sei annoiato.)

Sidenote lungo e sconclusionato

Documentazione sloppy openssl.

La documentazione openssl per DH effimero sembra essere stata contaminata dalla documentazione di openssl per RSA effimera. eRSA è una cosa del passato e non più supportato, ma ha fatto la stessa cosa per cui usiamo ora DH / ECDH effimero.

Quindi che cosa ha a che fare con DH / ECDH? Bene, la documentazione per SSL_OP_SINGLE_DH_USE si legge così:

SSL_OP_SINGLE_DH_USE
Always create a new key when using temporary/ephemeral DH parameters [...]

Ma aspetta un attimo! Secondo la solita terminologia openssl, la KEY è la parte effimera della combo parametro / chiave. Quindi, perché usano persino un termine come parametri temporanei / effimeri DH . - Beh, penso che l'abbiano appena copiato dalla documentazione per l'eRSA (ora morto e sepolto).

Quindi, mentre aveva senso dire per eRSA :

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

Non ha senso copiarlo in documentazione per eDH :

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

Questo è copiato letteralmente dal vecchio esempio di eRSA. E nel contesto DH questo non ha senso. Ciò che è costoso non è tanto rigenerare il DH-KEY, ma rigenerare il DH-GROUP.

Modifica 2017-07-23Sun: rimosso errato "puoi condividere il tuo modulo, nessun problema".

• Se non hai generato la chiave tu non puoi essere sicuro che non sia con una back-door

• Se una chiave è condivisa con un numero di server sufficiente, diventa più attraente e più economica da decifrare.