Java 1.5 java.security.InvalidAlgorithmParameterException: размер Prime должен быть кратен 64 и может находиться в диапазоне от 512 до 1024 (включительно)
Мы создали клиентский проект веб-службы Java с использованием Axis для подключения и вызова веб-службы. Наш Java-клиент развернут в JBOSS 4, использующем Java JDK 1.5.
Мы столкнулись с проблемой SSLHandshake: Prime size должен быть кратен 64 и может варьироваться только от 512 до 1024 (включительно) (ниже приведено исключение).
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
Мы заметили, что эта проблема с Java была решена в последних версиях Java (начиная с JDK 1.7.0_80). Но, к сожалению, мы не можем перейти на более новую версию Java.
Мы также попробовали обходной путь, предложенный с помощью провайдера BouncyCastle, но безуспешно. В этом случае мы получаем следующее исключение:
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
Кто-нибудь сталкивался с этой проблемой в прошлом?
Рассматривали ли вы возможность использования обратного прокси-сервера для ваших нужд SSL?
@tgdavies Не могли бы вы рассказать мне, как это сделать? Я не знаком с идеей. Я не прошу решения. Я прошу просто краткое руководство, чтобы выполнить возможный обходной путь.
@JoachimSauer Иногда есть клиенты, которые очень привязаны к своим приложениям. Мы должны рассмотреть обходной путь.
@DimitriosPavlis: я знаю. Это не меняет того факта, что поддержание связи такой системы с внешним миром граничит с небрежностью. Как вы примирите эти противоречивые тяги в разных направлениях, зависит от вас. Я ясно выразил свое мнение по теме.
@JoachimSauer Я согласен с тобой. Определенно. Не могли бы вы посоветовать мне, как решить проблему, зная, что мы не можем обновить Java?
@DimitriosPavlis: я не могу, я не знаю, какие у вас есть варианты (и, учитывая, что я не хотел бы делать это сам, мне не хочется тратить энергию на их исследование). Однако предложение tgdavies звучит разумно: поместите обратный прокси-сервер между JDK и целью, который переводит из современного/вероятно безопасного протокола, с которым работает служба, в древний/вероятно небезопасный протокол, с которым может говорить JDK.
@DimitriosPavlis просто из интереса, почему обновление JDK невозможно?
Как это размещается? Вы можете использовать услуги, например, AWS в качестве своего прокси. Вы используете такую службу, как Lambda, которая вызывается вашей службой, и она вызывает «настоящую» службу.
@tgdavies Клиент не хочет обновлять JBoss. Ужасно я знаю.
Ответы 1
Вы можете использовать обратный прокси-сервер, чтобы позволить клиентам подключаться к обратному прокси-серверу с помощью https, в то же время предоставляя внутреннюю службу через http.
Очевидно, вы должны быть уверены, что конфигурация вашей сети не позволит никаких внешних подключений напрямую к вашему серверу приложений, поскольку, если клиенты начнут подключаться через http, их учетные данные будут уязвимы.
Этот подход не смягчит другие проблемы безопасности с JDK и библиотеками, которые вы используете, например. если вы использовали версию ognl с уязвимостями.
Вот документация по использованию nginx в качестве обратного прокси:
Извините за мой поздний ответ. Пробуем установить Membrane ESB. Я хочу искренне поблагодарить вас от всего сердца. Вы привели нас к решению. У нас есть некоторые проблемы с вызовами HTTPS SOAP, но мы собираемся найти решение.
Мы настроили его правильно, и мы достигли нашей цели. Большое спасибо!
Если вы не можете обновить JDK версии 1.5, то ваше приложение не должно пытаться взаимодействовать с какой-либо внешней службой, потому что есть вероятность, что ваше приложение и JDK пронизаны хорошо известными, уязвимыми и активно эксплуатируемыми проблемами безопасности. Особенно, если ваше приложение пытается что-то сделать с SSL. Возможно, есть способ исправить это, не обновляя ваш JDK, но лично я бы этого не делал, потому что крайне безответственно выставлять напоказ систему, работающую на такой древней платформе.