Why is the reuse of the Elliptic curve Diffie–Hellman (ECDH) public server param considered bad?

Question

When reviewing the SSL/TLS configuration using Qualys SSL Labs, I've found that the reuse of the Elliptic curve Diffie–Hellman (ECDH) public server param was flagged.

Why is the reuse of the Elliptic curve Diffie–Hellman (ECDH) public server param considered bad?

Answer 1

Note: I'm deliberately ignoring the difference between regular DH and elliptic curve DH. Doesn't matter here.

Just poor phrasing.

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

I think this is just poor phrasing/terminology. SSL Labs uses the definition as per RFC to basically tell you "Yo, i received the same pubkey twice! This shouldn't happen!"

SSL Labs uses the terms DH public server param (Ys) and ECDH public server param for this.

And this only makes sense if you know that they're referring to the RFC definition of what makes up the "parameters" and not to the openssl definition of what makes up "dhparams".

RFC definition

As per the TLS 1.2 RFC the params are defined like so:

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

So they DO INCLUDE the pubkey (dh_Ys).

OpenSSL definition

But this conflicts with OpenSSL use of the term params which DOES NOT include the 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)

Only the prime and the generator are including. No PubKey.

Further reading:

• An earlier answer of mine.

---

(Read part below only if you're bored.)

---

Long and rambling Sidenote

Sloppy openssl documentation.

The openssl documentation for ephemeral DH seems to have been contaminated from the openssl documentation for ephemeral RSA. eRSA is a thing of the past and no longer supported but it did the same thing that we now use ephemeral DH/ECDH for.

So what does that have to do with DH/ECDH? Well, the documentation for SSL_OP_SINGLE_DH_USE reads like this:

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

But wait a minute! According to the usual openssl terminology the KEY is the ephemeral part of the parameter/key combo. So why do they even use a term such as temporary/ephemeral DH parameters. -- Well, I think they just copied that from the documentation for the (now dead and buried) eRSA.

So while THIS made sense to say for eRSA:

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

It does NOT make sense to copy that to the documentation for eDH:

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

This is copied verbatim from the old eRSA example. And in the DH context this does NOT make sense. What is costly is not so much to regenerate the DH-KEY but regenerate the DH-GROUP.

Edit 2017-07-23Sun: Removed wrong "you can share your modulus, no problem" statement.

Answer 2

• If you didn't generate the key yourself you can't be sure it's not with a back-door

• If a key is shared with enough servers, it became more attractive, more cost-efficient to crack it.

Answer 3

Although this (my own) question has been marked answered some time ago. I feel that this topic is in my opinion way too hard to fully explain to someone in an easy way, or to understand.

The other answers in this thread mainly explain that it is a common misconfiguration and not clearly "why it is bad", what the risk is. And that was actually the question. So, let me try to rephrase a bit and answer it in a more accessible/understandable way. This is to my recent understanding of it, so please correct me if I'm wrong.

---

What is the actual security risk of "ECDH public server param reuse" as reported by Qualys SSLLabs?

The actual security risk of "ECDH public server param reuse" is that perfect forward secrecy (PFS) is lost. Losing perfect forward secrecy (PFS) means that in case of a compromised server private key all (previously intercepted encrypted) communication can be decrypted. Which is prevented by the use of ephemeral Diffie-Hellman (read: not reusing the ECDH public server param).

The cause is not a misconfiguration in my opinion but rather an incorrect implementation of the the Diffie-Hellman modes EDH or DHE when using Elliptic-curve Diffie-Hellman (ECDH) with Transport Layer Security (TLS).

I used all these sources to get a clearer understanding of the matter:

1. Why is the reuse of the Elliptic curve Diffie–Hellman (ECDH) public server param considered bad?
2. What is ECDH public server param reuse?
3. https://en.wikipedia.org/wiki/Forward_secrecy
4. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
5. https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman
6. https://www.youtube.com/watch?v=IkM3R-KDu44 (great explanation of Perfect Forward Secrecy)