2

What is ECDH public server param reuse?

Anders
  • 64,406
  • 24
  • 178
  • 215
Mohamad Haidar
  • 349
  • 6
  • 13
  • Does this answer you? https://security.stackexchange.com/questions/165389/why-is-the-reuse-of-the-elliptic-curve-diffie-hellman-ecdh-public-server-param – schroeder Feb 02 '20 at 13:11
  • Thanks @schroeder. That is a little bit complex for someone new to the topic but I will try to catch up – Mohamad Haidar Feb 02 '20 at 13:18

1 Answers1

11

"ECDH public server param reuse" is when a server uses the same DH key value for multiple handshakes, instead of generating a new one for every handshake. The DH should be "ephemeral", that is why it's called "DHE" or "ECDHE", and this means the key is single-use and should never be reused.

Generating a new NIST P-256 ECDH or X25519 key is cheap, so there is no need to reuse it for performance reasons, but some SSL accelerator appliances do that. This is bad and they should be patched/configured to not do that.

@Mohamad

I have answered your question. It seems you do not know how TLS works. There are good explanations on this site about how TLS works. ECDHE uses a cleartext channel to establish a shared secret between two parties, then RSA or ECDSA signatures are used to establish identity of server or both server and client, then authenticated encryption (AEAD) is used to protect confidentiality and ensure data was not modified in transit.

"ECDH public server param reuse" refers to a small thing (about a single line of code) that is done wrong by a TLS server. It violates the forward secrecy property of ephemeral DH. It might be done on purpose, to enable decryption of traffic immediately by an appliance or later from an archive. It might be a performance optimization. It might be indication your software or firmware needs an update. It might be a configuration issue. Without more information, we don't know.

A TLS server has a great many lines of code, most of which are important to security. Unfortunately, it is possible to deploy an interoperable implementation that has some of those wrong (or missing). So the software/appliance seems to work (Chrome connects to such a server, or your client is able to connect to a standard server like Apache or IIS), but actually has a security problem.

A bunch of common errors/issues have names, and this is one of them.

If you know the general layout of an implementation, you should know where this line of code is. If you know the configuration API of a library or the configuration UI of an appliance, you should know where the toggle is.

Your question is a little of an XY problem. Tell us what you actually have and what you want, and we will be able to help you. For example, if you manage/operate a web site and you used Qualys SSL Server Test tool and got this issue, and you tell us how TLS termination is done for your site (e.g. version of MS IIS, version of F5 appliance, etc.), we might be able to tell you how to fix it.

I see you're an ASP.NET developer. Versions of MS IIS that have the "ECDH public server param reuse" issue do not have a configuration that can affect this. The software does this by design. The DH key is cached and regenerated periodically, but not for every connection, for performance reasons. Since the key is not stored on disk and is not completely static, it's not so bad, but it's not great. Possibly newer versions of IIS don't do this, but I don't know.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
  • Thank you so much man. I need to read a little bit about this topic since it is a bit out of my area of expertise. One last thing, if you look the below diagram and If I am understanding correctly, I would say that DH key is equivalent to the public key in the below diagram, correct? https://i.stack.imgur.com/N12Ln.png – Mohamad Haidar Feb 03 '20 at 15:51
  • 1
    The DH key is the keypair (private and public together). The tester of course can only see the public the server sends. If the tester performs two connections and the server sent the same public in both, this warning is triggered. – Z.T. Feb 03 '20 at 16:05