ssl - Java 7 and Could not generate DH keypair

Question

I read a previous post regarding the error 'Could not generate DH keypair' fired when the server sents a key longer than 1024 bits. Downloading the JCE unlimited jars should fix this issue. In the test environment I have I encountered the following, for the same web server if I use Java 6 I don't get any errors when performing the https query but if I use Java 7 then I get 'Could not generate DH keypair'.

I tried replacing the jar files for JCE unlimited but still get the same error. The bug is reported since 2007, but why does it run for Java 6 and not for Java 7? Are the files to download not the proper ones? I got the link from a previous post Java: Why does SSL handshake give 'Could not generate DH keypair' exception?.

At this point I don't know what to do. If I try to load the BouncyCastle provider I get an ArrayOutOfIndex exception. My server only allows DH algorithm so I can't use another algorithm like suggested in the above post.

Answer 1

Some additions or clarifications:

(Suncle) Java 7 since 7u09 uses a more sensible consistent order of ciphersuites by default, unlike the seemingly random order in 7u04. (I don't have tests between 04 and 09.) This order puts ECDHE and plain-RSA (aka akRSA) before DHE, and thus avoids the problem if AND ONLY IF the server supports ECDHE or RSA and agrees to client preference. (Or ECDH-fixed, but practically nobody uses that.) If the server insists on DHE (for whatever reason) AND uses DH>1024 bits, you still have the problem.

If the asker (or anyone else) connects to a server that truly requires integer-DH (and not ECDH or RSA), the only way to work with Java before 8 is to get the server to use DH 1024-bit. Which AFAWK is technically secure for a few more years, but with a thin margin it is prohibited by important authorities like NIST (see Special Pub 800-57 at csrc.nist.gov). (Even RSA 1024 isn't actually broken yet, but it probably will be soon and so is prohibited.)

The "unlimited strength policy" is not relevant to this problem, or at least not directly, and the good answers to #6851461 did not say it is. It does not change the restriction on DH parameters in SunJCE, which is (wrongly) treated as a standard issue not a strength issue. (Specifically it takes the restrictions that used to be correct for DSA, and applies them to DH.) It does enable AES-256 and SHA-2 (only for TLSv1.2) suites, and given a sufficiently strange preference list, that might change the selection result from DHE (fails) to non-DHE (works).

You don't need to go entirely back to the Java 6 list, you just need to prioritize other key exchanges over DHE, or for a recalcitrant server drop DHE entirely. You definitely should NOT go back to enabling any EXPORT or single-DES suites, unless absolutely needed for a legacy server; they have been NOT SECURE for several years now, and remained enabled by default in 6 far longer than they should have.