1
$\begingroup$

I am not a beginner in crypto, but not that far from it, so please be gentle.

I look after a web server app that I generated the SSL certificate for, and I used an RSA public/private keypair.

When connecting to the web app via firefox 40.0.3, it doesn't let me, with Error code: ssl_error_weak_server_ephemeral_dh_key

As I understood it using RSA or Diffie Hellman for session key exchange did similar things, but were entirely separate.

So how can I have Diffie Hellman vulnerabilities if I am not using it?

P.S. The web app is HP Network Automation 9.20, which is based on jboss.

Sorry if this is the wrong exchange, the other questions I see look more pure maths based than applied crypto.

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ Jboss web server is based on Tomcat, which can implement SSL/TLS two ways, using Java (JSSE) or "native" which is really OpenSSL. Which does your startup log say you are using? If Java and you are running on Java6 it will not be secure. Java7 can do ECDHE and Firefox will be happy, unless something in your app or config blocks ECDHE, in which case DHE is still weak. Java8 can do ECDHE or strong-enough DHE. If "native" OpenSSL that should be okay but may require further investigation. $\endgroup$
    – dave_thompson_085
    Commented Sep 11, 2015 at 7:30

2 Answers 2

Reset to default
2
$\begingroup$

There are two different ways a RSA certificate can be used by a SSL/TLS server.

In the "classical" RSA ciphersuites the client randomly picks a secret value, encrypts it with the public key from the server certificate and sends it to the server. The server uses the private key to decrypt it. So the client and server now have a shared secret.

The downside of this approach is that it does not provide "forward secrecy", if the server's private key is later stolen then all previous sessions can be decrypted.

To solve this problem the "ephemeral" cipher suites were introduced where the keys used for the key exchange are generated for a given session and then thrown away. In principle an epheral RSA ciphersuite is possible, but no modern ciphersuite uses that technique for performance reasons (generating RSA keys is computationally intensive).

So in modern "ephemeral" cipersuites the clients agree a shared secret using an epheral DH or ECDH exchange. The RSA (or DSA or ECDSA) key in the certificate is used to sign the key exchange so that the client knows it is communicating with the correct server. These ciphersuites have names like TLS_DHE_RSA_(something) or TLS_ECDHE_RSA_(something) .

The strength of the DH or ECDH keys used in the key exchange itself is independent of the strength of the RSA key used to verify the key exchange. Some older servers default to 1024 bit or worse 768 bit DH parameters.

The preffered option is to set up your server to use 2048 bit or stronger DH parameters. If for some reason that is not possible you should disable the DHE ciphersuites, though be aware that this may cause you to lose forward-secrecy with some clients.

Improve this answer
$\endgroup$
1
$\begingroup$

The connection is probably negotiating a DHE_RSA cipher suite. RSA signatures are used to authenticate the ephemeral Diffie-Hellman keys used for the actual key exchange. That is a good thing, because cipher suites that use RSA for both the authentication and the key exchange do not offer forward secrecy.

To fix this, you should make sure the server uses 2048-bit Diffie-Hellman keys, or move to elliptic curves.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.