4

I am trying to increase the DH key size from 1024 bits to 2048 bits, as per this question: How to expand DH key size to 2048 in java 8.

However, it does not seem to work. Relevant information:

java -version
java version "1.8.0_45" 
Java(TM) SE Runtime Environment (build 1.8.0_45-b14) 
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

And

System.out.println(Security.getProperty("jdk.tls.ephemeralDHKeySize"));
2048

However, if I connect to that server from a client, it uses 1024-bit:

openssl s_client -connect server:port -cipher "EDH" 2>/dev/null | grep -ie "Server .* key"
Server Temp Key: DH, 1024 bits

Any idea what else I can do?

Community
  • 1
  • 1
Michael
  • 363
  • 5
  • 20
  • Just a blind guess: Maybe the key size is restricted by the security policy? Have you tried to install the unlimited strength policy? http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html – Cybran Apr 03 '16 at 16:22
  • What platform are you running on? What version of openssl are you using to connect? (`openssl version` will tell you) – Pete Clark Apr 03 '16 at 17:18
  • Redhat 6 platform, openssl version to check, i think 1.0.2g – Michael Apr 03 '16 at 21:16
  • @DevCybran, yes, the unlimited strength policy is installed – Michael Apr 03 '16 at 21:17
  • @DevCybran Unlimited Strength Policy only affects symmetric -- at least in Oracle; ISTR seeing an IBM-Java version that restricted asymmetric also and I don't remember if that included/was DH. But that version is Oracle. – dave_thompson_085 Apr 03 '16 at 22:40
  • 1
    @PeteClark That output implies openssl 1.0.2 or up (which at present is only 1.1.0-alpha or head); openssl has supported DH size at least 65536 back at least to 0.9.7 in 2002. (And sort-of DSA also, even before FIPS186-3 standardardized >1024, but with inconvenient restrictions: it couldn't generate params with a subgroup larger than 160, so you had to do that by hand, and the EVP API and commandline couldn't sign/verify with a hash other than SHA1, so you had to use lowlevel APIs.) As your answer says, the issue is it's a system property. – dave_thompson_085 Apr 03 '16 at 22:41
  • @PeteClark + BTW, Redhat -- and most other Linux distros I know of -- don't take whole new versions of 3rd-party packages into a release but instead backport selected/critical patches. `openssl version` says only the upstream version; in general check `yum` or `rpm` (or `apt` or `dpkg` or `dnf` etc) to see if&how the version you are running differs from upstream. But this case isn't an openssl version issue anyway. – dave_thompson_085 Apr 03 '16 at 22:46

1 Answers1

1

I'm concerned that you're calling Security.getProperty("jdk.tls.ephemeralDHKeySize") to check the DH key size. The jdk.tls.ephemeralDHKeySize property is not a Security property, it's a System property, which leads me to suspect that you're not setting it properly. If you're setting it like this:

Security.setProperty("jdk.tls.ephemeralDHKeySize", "2048"); // don't do this

then that's not going to work. Try either passing:

-Djdk.tls.ephemeralDHKeySize=2048

in the command-line of your program, or set it like this:

System.setProperty("jdk.tls.ephemeralDHKeySize", "2048");

in code.

Pete Clark
  • 584
  • 4
  • 8
  • 3
    If you set in code be sure it's before first SSL operation -- before `sun.security.ssl.ServerHandshaker` is classloaded, because the property is checked then and cached. – dave_thompson_085 Apr 03 '16 at 23:07
  • @Pete Clark, hmm interesting. I actually do not set it in code, I set it in the 'java.security' file, which can be found in JavaHome/jre/lib/security. Then, if I do 'System.getProperty', it does not find the value (null). It only finds it when I do 'Security.getProperty'. So basically you think that setting it through the java.security file is incorrect? – Michael Apr 04 '16 at 06:42
  • @Pete Clark, solved! Passing -Djdk etc. with the command worked. Any idea why the java.security properties do not work? I would think that these settings apply to the whole JVM, so that I do not have to set them separately for each process that runs inside that JVM? – Michael Apr 04 '16 at 07:51
  • @Michael - sorry - I don't know. I'm generally reluctant to change stuff in the jre folders, since that's not guaranteed to be preserved if/when the JRE or JDK is updated, and can lead to sadness post-deployment. – Pete Clark Apr 04 '16 at 17:30