Java 1.5 java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)

Question

We have built a Java Web service client project using Axis in order to connect and call a Web Service. Our Java client is deployed in JBOSS 4 that is using Java JDK 1.5.

We are facing an issue with the SSLHandshake: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive) (below is the exception).

    AxisFault

    faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException

    faultSubcode:

    faultString: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH 
    
    keypair
    
    faultActor:

    faultNode:

    faultDetail:

            {http://xml.apache.org/axis/}stackTrace:javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair

            at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:166)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1518)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1485)

            at 
    com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1468)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1064)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)

            at 
    org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)

            at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)

            at org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:404)

            at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:138)

            at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)

            at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)

            at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)

            at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)

            at org.apache.axis.client.Call.invokeEngine(Call.java:2784)

            at org.apache.axis.client.Call.invoke(Call.java:2767)

            at org.apache.axis.client.Call.invoke(Call.java:2443)

            at org.apache.axis.client.Call.invoke(Call.java:2366)

            at org.apache.axis.client.Call.invoke(Call.java:1812)

            at gr.spdxws.AccessPointSoapStub.createSession(AccessPointSoapStub.java:935)

            at gr.spdxws.AccessPointSoapProxy.createSession(AccessPointSoapProxy.java:79)

            at iperform.policies.tim.SpeedexWSTest.run(SpeedexWSTest.java:66)

            at 

     com.oakgrovesystems.reactor.services.policyExecution.AccessControlledScript$4.run(AccessControlledScript.java:111)

            at java.security.AccessController.doPrivileged(Native Method)

            at com.oakgrovesystems.reactor.services.policyExecution.AccessControlledScript.execute(AccessControlledScript.java:109)

            at com.oakgrovesystems.reactor.services.policyExecution.AccessControlledScript.run(AccessControlledScript.java:65)

            at com.oakgrovesystems.reactor.services.policyExecution.PolicyExecutor.execute(PolicyExecutor.java:290)

            at com.oakgrovesystems.reactor.services.policyExecution.PolicyExecutionMessageBean.execute(PolicyExecutionMessageBean.java:213)

            at com.oakgrovesystems.reactor.services.policyExecution.PolicyExecutionMessageBean.handleExecuteMessage(PolicyExecutionMessageBean.java:203)

            at com.oakgrovesystems.reactor.services.policyExecution.PolicyExecutionMessageBean.onMessage(PolicyExecutionMessageBean.java:117)

            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

            at java.lang.reflect.Method.invoke(Method.java:585)

            at org.jboss.invocation.Invocation.performCall(Invocation.java:359)

            at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:495)

            at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)

            at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:116)

            at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)

            at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)

            at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)

            at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)

            at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:109)

            at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)

            at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)

            at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:402)

            at org.jboss.ejb.Container.invoke(Container.java:954)

            at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:987)

            at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1287)

            at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266)

            at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:905)

            at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)

            at org.jboss.mq.SpySession.run(SpySession.java:323)

            at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)

            at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)

            at java.lang.Thread.run(Thread.java:595)

    Caused by: java.lang.RuntimeException: Could not generate DH keypair

            at com.sun.net.ssl.internal.ssl.DHKeyExchange.generateKeyPair(DHKeyExchange.java:137)

            at com.sun.net.ssl.internal.ssl.ClientHandshaker.getDHephemeral(ClientHandshaker.java:371)

            at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:386)

            at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:125)

            at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)

            at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)

            ... 51 more

    Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)

            at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA12275)

            at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:609)

            at java.security.KeyPairGenerator.initialize(KeyPairGenerator.java:351)

            at com.sun.net.ssl.internal.ssl.DHKeyExchange.generateKeyPair(DHKeyExchange.java:123)

            ... 59 more

We have noticed that this Java issue has been resolved in latest Java versions (from JDK 1.7.0_80). But unfortunately we cannot upgrade to a newer version of Java.

We have also tried a workaround proposed by using BouncyCastle provider, but with no luck. In that case we are getting the following exception:

    AxisFault

    faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException

    faultSubcode:

    faultString: javax.net.ssl.SSLException: java.lang.ArrayIndexOutOfBoundsException: 64

    faultActor:

    faultNode:

    faultDetail:

            {http://xml.apache.org/axis/}stackTrace:javax.net.ssl.SSLException: java.lang.ArrayIndexOutOfBoundsException: 64

            at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:166)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1584)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1547)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1530)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1100)

            at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)

            at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)

            at org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:404)

            at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:138)

            at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)

            at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)

            at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)

            at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)

            at org.apache.axis.client.Call.invokeEngine(Call.java:2784)

            at org.apache.axis.client.Call.invoke(Call.java:2767)

            at org.apache.axis.client.Call.invoke(Call.java:2443)

            at org.apache.axis.client.Call.invoke(Call.java:2366)

            at org.apache.axis.client.Call.invoke(Call.java:1812)

            at gr.spdxws.AccessPointSoapStub.createSession(AccessPointSoapStub.java:935)

            at gr.spdxws.AccessPointSoapProxy.createSession(AccessPointSoapProxy.java:79)

            at gr.spdxws.AccessPointSoapStub.main(AccessPointSoapStub.java:1679)

    Caused by: java.lang.ArrayIndexOutOfBoundsException: 64

            at com.sun.net.ssl.internal.ssl.PRF.expand(PRF.java:128)

            at com.sun.net.ssl.internal.ssl.PRF.compute(PRF.java:85)

            at com.sun.net.ssl.internal.ssl.Handshaker.doPRF(Handshaker.java:679)

            at com.sun.net.ssl.internal.ssl.Handshaker.calculateMasterSecret(Handshaker.java:655)

            at com.sun.net.ssl.internal.ssl.Handshaker.calculateKeys(Handshaker.java:618)

            at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:588)

            at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:160)

            at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)

            at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:877)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1089)

            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1116)

            ... 17 more

Did anybody face this issue in past?

If you can't upgrade away from a 1.5 era JDK, then your application should not attempt to communicate with any outside service, because odds are that your application and the JDK is riddled with well-known, exploitable and actively-exploited security issues. Especially if your application tries to do anything with SSL. There *might* be a way to fix this without upgrading your JDK, but personally I'd not do that, because it's wildly irresponsible to expose a system that's running on that kind of ancient platform. — Joachim Sauer, Dec 16 '20 at 10:43
Have you considered using a reverse proxy for your SSL needs? — tgdavies, Dec 16 '20 at 10:49
@tgdavies Could you guide me about how to accomplish that? I am not familiar with the idea. I am not asking for the solution. I am asking just a quick guide in oder to accomplish a possible workaround. — Dimitrios Pavlis, Dec 17 '20 at 15:16
@JoachimSauer Sometimes there are customers that they are very attached to their apps. We have to consider a workaround. — Dimitrios Pavlis, Dec 17 '20 at 15:17
@DimitriosPavlis: I know. That doesn't change the fact that keeping such a system connected to the outside world borders on negligence. How you reconcile those conflicting pulls in different directions is up to you. I made *my* view on the topic clear. — Joachim Sauer, Dec 17 '20 at 15:53
@JoachimSauer I agree with you. Defenitely. Could you advise me how to overcome the issue knowing that we cannot upgrade Java? — Dimitrios Pavlis, Dec 17 '20 at 16:09
@DimitriosPavlis: I can not, I do not know what options there are for you (and given that I'd not want to do this myself I don't feel like investing energy into resarching them). The suggestion by tgdavies sounds reasonable, though: put a reverse proxy between the JDK and the target that translates from the modern/probably safe protocol that the service speaks to the ancient/probably unsafe one that the JDK can speak. — Joachim Sauer, Dec 17 '20 at 18:35
@DimitriosPavlis just out of interest, why is a JDK upgrade not possible? — tgdavies, Dec 17 '20 at 22:56
How is this hosted? You may be able to use the services of, for example, AWS to be your proxy. You use a service such as Lambda that is called by your service and it calls the "real" service. — stdunbar, Dec 17 '20 at 23:12
@tgdavies Customer does not want to upgrade JBoss. Awful I know. — Dimitrios Pavlis, Dec 18 '20 at 16:27

score 1 · Accepted Answer · answered Dec 17 '20 at 22:48

You can use a reverse proxy to allow clients to connect the reverse proxy using https while internally exposing the service over http.

Obviously you should be sure that your network configuration won't allow any external connections directly to your app server, as if clients started connecting via http their credentials would be vulnerable.

This approach will not mitigate any other security issues with the JDK and libraries you are using, e.g. if you were using a version of ognl with vulnerabilities.

Here's documentation on using nginx as a reverse proxy: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/?_ga=2.104366976.1869010128.1608244655-193116785.1608244655

Sorry for my late respond. We try to set Membrane ESB. I want to really thank you from my heart. You guided us to the solution. We have some issues with https SOAP calls but we are going to find the solution. — Dimitrios Pavlis, Dec 22 '20 at 12:08
We set it up properly and we reached our goal. Thank you very much! — Dimitrios Pavlis, Dec 23 '20 at 17:23

Java 1.5 java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)

1 Answers1