The JDK implementation of TLS 1.2 uses a DH keysize of 1024 bits (chosen by the server) when a TLS_DHE cipher suite is negotiated and either the client or server does not support FFDHE to negotiate a stronger keysize.

1024-bit DH keys are known to be weak and are no longer recommended. Using this default should be rare under normal circumstances. A server or client would need to be configured such that no stronger suite is available that they both support and one or the other do not support FFDHE. The TLS_DHE cipher suites are lower in priority than other suites, and JDK implementations 8u261 and up all support FFDHE, which will only negotiate DH keys >= 2048 bits. But increasing this default size is still important, as a Java server may be negotiating with a non-Java TLS client that does not support FFDHE.

There was a concern in the past that some TLS clients may not support DH keys greater than 1024 bits, but this should now be very low risk. Most leading web browsers have deprecated the TLS_DHE suites so this should not be an issue. My testing shows no issues in the latest updates of JDK 6u and up, or OpenSSL 1.0.2 or later. JDK 1.5 was the last Java release that did not support DH keys greater than 1024-bits but that is a legacy release that has been unsupported for many years now.

As a workaround, users can revert to the previous size by setting the "jdk.tls.ephemeralDHKeySize" system property to 1024 (at their own risk).

This issue does not affect TLS 1.3 as the minimum DH group size is 2048 bits.