Running a maven build that retrieves some artifacts from fedorahosted.org, I ran into the following issue. http://paste.stg.fedoraproject.org/4688/ (full log) Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1917) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1874) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1857) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1378) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:864) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:259) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:136) at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:686) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:264) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:936) at sun.security.ssl.Handshaker.process_record(Handshaker.java:871) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1043) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371) ... 12 more Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive) at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120) at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:657) at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127) ... 19 more I've seen various commits/bugs showing the limit has increased from 1024, to 2048, but Fedora infrastructure seems to use a key size of 4096 (https://fedorahosted.org/fedora-infrastructure/ticket/2569). Omair mentioned this limit is hard-coded so it doesn't seem like a workaround would be possible except by patching the the package itself. Would it be possible to increase this limit and possibly coordinate with fedora-infra ?
Indeed. The recent change we made in OpenJDK 7 [0] was a backport from 8 to bump the limit from 1024 to 2048. We'd have to do something similar to support higher values and it would need considerable testing. [0] http://bitly.com/it20503
Hmm, this key size change has been done 3 years ago according to this ticket. I'm not buying it that this is *only* caused by the DH keysize hard-coded limits. My memory might trick me but there were also changes to the priority of ciphers used during TLS handshakes. I can't find this change at the moment. In any case I'll try to come up with a simple reproducer and will report back. The other day Alex also pointed me to: http://osdir.com/ml/general/2014-11/msg18681.html So there is value to find out if the keysize is between (1024,2048) bits. I.e. *not* 1024 or 2048. Thanks for the bug report, Roland!
It would also be good to know if this really *only* happens with java-1.8.0-openjdk and if this is reproducible 100%
Created attachment 957159 [details] Minimal reproducer
This happens for java-1.7.0-openjdk too. Run the reproducer via: $ javac DHHandshakerTest.java $ java DHHandshakerTest Expected result: Supported ciphers: [<ciphers-supported-by-jdk>] Tusting all certificates! Handshake done! Test passed Actual result for java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64: Supported ciphers: [<ciphers-supported-by-jdk>] Tusting all certificates! Exception in thread "main" java.lang.RuntimeException: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at DHHandshakerTest.main(DHHandshakerTest.java:31) Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1884) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1842) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1825) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1346) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at DHHandshakerTest.establish(DHHandshakerTest.java:59) at DHHandshakerTest.main(DHHandshakerTest.java:29) Caused by: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:136) at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:681) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:261) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:878) at sun.security.ssl.Handshaker.process_record(Handshaker.java:814) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) ... 3 more Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive) at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120) at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:658) at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127) ... 10 more Actual result with java-1.8.0-openjdk-1.8.0.25-2.b18.fc20.x86_64: Supported ciphers: [<ciphers-supported-by-jdk] Tusting all certificates! Exception in thread "main" java.lang.RuntimeException: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at DHHandshakerTest.main(DHHandshakerTest.java:31) Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1917) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1874) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1857) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1378) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355) at DHHandshakerTest.establish(DHHandshakerTest.java:59) at DHHandshakerTest.main(DHHandshakerTest.java:29) Caused by: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:136) at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:686) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:264) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:936) at sun.security.ssl.Handshaker.process_record(Handshaker.java:871) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1043) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371) ... 3 more Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive) at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120) at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:657) at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127) ... 10 more
If I restrict the ciphers to RSA only ciphers the handshake fails early on. This suggests that the fedorahosted.org server does not accept any RSA ciphers. If this is confirmed that a possible work-around would be to restrict ciphers to not use DH as follows. ciphers.retainAll(Arrays.asList( "TLS_RSA_WITH_AES_128_CBC_SHA256", "TLS_RSA_WITH_AES_256_CBC_SHA256", "TLS_RSA_WITH_AES_256_CBC_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "SSL_RSA_WITH_3DES_EDE_CBC_SHA", "SSL_RSA_WITH_RC4_128_SHA1", "SSL_RSA_WITH_RC4_128_MD5", "TLS_EMPTY_RENEGOTIATION_INFO_SCSV")); params.setCipherSuites(ciphers.toArray(new String[ciphers.size()])); // Create the socket and connect it at the TCP layer. SSLSocket socket = (SSLSocket) ctx.getSocketFactory() .createSocket("fedorahosted.org", 443); // Adjust ciphers and protocols. socket.setSSLParameters(params); // Perform the handshake. socket.startHandshake(); I still need to investigate what exactly is failing when DH ciphers are used. I.e. if the prime size is not a multiple of 64 or if it's not in [512,2048].
(In reply to Severin Gehwolf from comment #6) > If this is confirmed that a possible work-around would be to > restrict ciphers to not use DH as follows. The possible work-around would be to convince admins to allow an RSA cipher and restrict the Java client side to RSA ciphers as shown above.
Created attachment 957177 [details] JDK patch showing the prime bit length in exception
I've done a custom JDK 8 build with patch in comment 8, restricted cipher to "TLS_DHE_RSA_WITH_AES_128_CBC_SHA256" and ran the reproducer against fedorahosted.org. It looks like the prime size is 4096 bit. Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive). Size was: 4096 at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120) at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:674) at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127) ... 10 more
Yes, 4096 is what https://fedorahosted.org/fedora-infrastructure/ticket/2569 requested.
(In reply to Andrew John Hughes from comment #10) > Yes, 4096 is what https://fedorahosted.org/fedora-infrastructure/ticket/2569 > requested. Right. It's still strange that it's surfacing only now. If that ticket is to be believed then it was changed 3 years back. My guess is that fedorahosted.org disabled RSA ciphers server side (see comment 6) which brought this problem to the surface. It might be some additional coincidental change that happened too and we haven't known until now.
Replicated with a build with EC disabled: $ /mnt/builder/icedtea7/j2sdk-image/bin/java DHHandshakerTest Supported ciphers: [TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Tusting all certificates! Exception in thread "main" java.lang.RuntimeException: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at DHHandshakerTest.main(DHHandshakerTest.java:31) Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1884) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1842) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1825) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1346) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at DHHandshakerTest.establish(DHHandshakerTest.java:59) at DHHandshakerTest.main(DHHandshakerTest.java:29) Caused by: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:136) at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:681) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:261) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:878) at sun.security.ssl.Handshaker.process_record(Handshaker.java:814) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) ... 3 more Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive) at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120) at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:658) at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127) ... 10 more Passes with EC: $ java DHHandshakerTest Supported ciphers: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Tusting all certificates! Handshake done! Test passed I'll look into a patch.
I can connect when this patch is applied: http://icedtea.classpath.org//hg/icedtea7-forest/jdk?cmd=changeset;node=d318d83c4e74 (this is with 7, but the code hasn't changed in 8)
*** Bug 1185345 has been marked as a duplicate of this bug. ***
Ouch, I am the guy who requested key size of 4096 for fedoraproject.org - and now I run into this issue myself. Can we get the fix (whatever it is) into the Fedora packages as well)? java-1.7.0-openjdk-1.7.0.75-2.5.4.0.el6_6.x86_64 seems to work here while older java-1.7.0-openjdk-1.7.0.71-2.5.3.1.el6.x86_64 does not.
I don't follow you. You should be using java-1.7.0-openjdk-1.7.0.75-2.5.4.0.el6_6.x86_64 which has the fix.
I get "java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)" java-1.8.0-openjdk-1.8.0.31-3.b13.fc21.x86_64
(In reply to Andrew John Hughes from comment #13) > I can connect when this patch is applied: > > http://icedtea.classpath.org//hg/icedtea7-forest/jdk?cmd=changeset; > node=d318d83c4e74 > > (this is with 7, but the code hasn't changed in 8) hi! It does a bit. Now the method is: private static void checkKeySize(int keysize) throws InvalidAlgorithmParameterException { if ((keysize != 2048) && ((keysize < 512) || (keysize > 1024) || (keysize % 64 != 0))) { throw new InvalidAlgorithmParameterException( "Keysize must be multiple of 64 ranging from " + "512 to 1024 (inclusive), or 2048"); } } Is - ((keysize < 512) || (keysize > 1024) || (keysize % 64 != 0))) { + ((keysize < 512) || (keysize > 4096) || (keysize % 64 != 0))) { - + "512 to 1024 (inclusive), or 2048"); + + "512 to 4026 (inclusive), or 2048"); ok by you?
Created attachment 1012238 [details] Patch variant for OpenJDK 8 post-7196382
7196382: PKCS11 provider should support 2048-bit DH also included some refactoring. The attached patch will work with 8.
I just found this bug and thought I'd chime in to explain why this only hit October 2014: at October 13, 2014, we changed our configuration, disabling all ciphers except for strong DHE and ECDHE based ciphers. The ticket pointed to is only to replace the certificate size, which is not the problem here: the problem is the DH parameter size, which was only increased with the change on October 13th.
For those interested, our current ciphersuite configuration is at: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/httpd/templates/website.conf.j2#n46
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Is this bug still an issue? The suggested fix is present in the packages: http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/rh1163501.patch?h=f22 And has been built, as far as I can tell, since java-1.8.0-openjdk version 1.8.0.60-14.b24
I'm no longer able to reproduce the issue with java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64 or java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64 running maven so I guess this is resolved.
If Fedora has synced with the RHEL packages where I added the fix for this, then yes, it is fixed.