10

The new Logjam attack on TLS is based on common DH groups. This link recommends generating a new, custom 2048-bit DH group for each server.

How can I set a custom DH group in Java server code which uses SSLEngine?

ETA: would I be safe if I used only ephemeral DH cipher suites, i.e. ones with DHE or ECDHE and not DH or ECDH in their name? Or is this unrelated?

danarmak
  • 1,190
  • 1
  • 10
  • 19
  • Logjam applies only to ephemeral integer DH where the server uses weak parameters because export is forged (DHE_EXPORT) or "normal" DHE is used but the server is stupidly configured/coded (section 3.5 of the paper). It would apply to static integer DH if you could get a cert for DH which in practice you can't, *and* the CA allowed stupidly weak parameters which they wouldn't. It doesn't apply to ECDH either ephemeral or static, and the paper recommends ECDHE as a fix in general but echos the suspicions of the currently common SECG/NIST curves specifically. – dave_thompson_085 May 23 '15 at 21:54
  • 1
    It is primarily the *weakness* (512 bits, probably 768 and maybe 1024) that makes the attack possible. Sharing only makes the attack more cost-effective, because you get more "output" for one "input". Shared 2048 would be fine *if* generated *verifiably* (so you can be certain it really has the strength of 2048). – dave_thompson_085 May 23 '15 at 22:01
  • 1
    @dave_thompson_085 And we have no way of knowing if the shared 2048 bit params in `sun.security.provider.ParameterCache` are safe? – danarmak May 24 '15 at 13:45
  • Actually the generation process is documented in the code comment. @danarmak – eckes May 26 '15 at 01:18

1 Answers1

7

Java (JCE/JSSE) uses DH parameters from some well known DSA groups. The JCE parameter generator allows only to produce groups with sizes between 512 and 1024 bit (or 2048), but the JSSE implementation on the other side only accepts custom sizes between 1024 and 2048.

This has the affect you cannot use any of the custom sizes, only 1024 or 2048 (with Java 8). Keep in mind that Java 7 still only uses 768 bit as a server (or 512 in exportable crypto mode).

Starting with version 8 Java servers use by default 1024 bit. You can increase the server side to 2048 bit with jdk.tls.ephemeralDHKeySize=2048. See Customizing Size of Ephemeral DH Keys.

Java as TLS client is less strict in older versions and accepts unsafe groups.

Update: with OpenJDK 8U65 (JSSE) there is a security property jdk.tls.server.defaultDHEParameters which can define finit-field parameters.

eckes
  • 10,103
  • 1
  • 59
  • 71
  • 1
    Thanks. The Logjam report recommends 2048-bit DH groups at a minimum, so I guess I'll have to look into using BC providers to manipulate that, since Java's probably can't be influenced. – danarmak May 23 '15 at 12:38
  • 2
    Actually, the Logjam report says 1024-bit DH primes are safe if they're generated and not shared/standard ones. So I guess Java 8 (server) is safe for now. Java 8 client may not be. – danarmak May 23 '15 at 12:52
  • I added the option to increase it to 2048 bit. – eckes May 23 '15 at 13:24
  • 2
    With the "standard" provider SunJCE, JSSE server uses one of the hardcoded parameter sets in `sun.security.provider.ParameterCache` not a newly generated one. And in the past I couldn't get JSSE to work with BC as a primitive provider, though I haven't retried recently. In all versions JSSE server selects DH-512 for an export suite (as per RFCs) otherwise 7 *or 6* uses 768 and 8 works as you indicate (default 1024, configurable up to 2048 or 768). – dave_thompson_085 May 23 '15 at 21:41
  • Yes your right, it only caches parameters different from the well known ones it seems. – eckes May 23 '15 at 23:19
  • 1
    So to sum up: the Java 8 server can be made to use 2048-bit DH keys, but always uses shared params, unless we can substitute the BC implementation. Or we could inject new params into `sun.security.provider.ParameterCache` using reflection. – danarmak May 24 '15 at 13:44
  • Yes, see also http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012221.html (and the "disableAlgorithm" thread on client side: http://mail.openjdk.java.net/pipermail/security-dev/2015-May/thread.html) – eckes May 24 '15 at 20:59
  • Updates 8u65 feature to actually define generator. – eckes May 24 '16 at 17:05