当我与一些IRC服务器(但不是其他服务器-可能是由于服务器的首选加密方法)建立SSL连接时,我得到以下异常:
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:183)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
... 3 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(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:100)
... 10 more
演示此问题的一个服务器示例是aperture.esper.net:6697 (这是一个IRC服务器)。未演示该问题的服务器的一个示例是kornbluth.freenode.net:6697。毫不奇怪,每个网络上的所有服务器都具有相同的各自行为。
我的代码(如上所述,在连接到一些SSL服务器时可以正常工作)是:
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(null, trustAllCerts, new SecureRandom());
s = (SSLSocket)sslContext.getSocketFactory().createSocket();
s.connect(new InetSocketAddress(host, port), timeout);
s.setSoTimeout(0);
((SSLSocket)s).startHandshake();
最后一个startHandshake抛出了异常。是的,‘trustAllCerts’有一些神奇之处;该代码迫使SSL系统不验证证书。(所以...这不是证书问题。)
显然,一种可能性是esper的服务器配置错误,但我搜索了一下,没有找到任何其他关于esper的SSL端口有问题的人的引用,'openssl‘连接到它(见下文)。所以我想知道这是不是Java默认SSL支持的限制,还是什么。有什么建议吗?
下面是我在命令行中使用'openssl‘连接到aperture.esper.net 6697时发生的情况:
~ $ openssl s_client -connect aperture.esper.net:6697
CONNECTED(00000003)
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
verify return:1
---
Certificate chain
0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
Server certificate
-----BEGIN CERTIFICATE-----
[There was a certificate here, but I deleted it to save space]
-----END CERTIFICATE-----
subject=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
No client certificate CA names sent
---
SSL handshake has read 2178 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 51F1D40A1B044700365D3BD1C61ABC745FB0C347A334E1410946DCB5EFE37AFD
Session-ID-ctx:
Master-Key: DF8194F6A60B073E049C87284856B5561476315145B55E35811028C4D97F77696F676DB019BB6E271E9965F289A99083
Key-Arg : None
Start Time: 1311801833
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
如上所述,在所有这些之后,它确实成功地连接了,这对我的Java应用程序来说是无法比拟的。
如果有必要的话,我使用的是OSX10.6.8,Java版本的1.6.0_26。
发布于 2011-07-29 00:30:50
上面的答案是正确的,但就解决方法而言,当我将BouncyCastle实现设置为首选提供程序时,我遇到了问题:
java.lang.ArrayIndexOutOfBoundsException: 64
at com.sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)
在我找到的一个论坛帖子中也讨论了这一点,但没有提到解决方案。http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems
我找到了一个适用于我的情况的替代解决方案,尽管我对它一点也不满意。解决方案是将其设置为Diffie-Hellman算法根本不可用。然后,假设服务器支持替代算法,它将在正常协商期间进行选择。显然,这样做的缺点是,如果有人设法找到了一个只支持1024位或更少的Diffie-Hellman的服务器,那么这实际上意味着它将不能在以前工作的地方工作。
下面是给出一个SSLSocket的代码(在你连接它之前):
List<String> limited = new LinkedList<String>();
for(String suite : ((SSLSocket)s).getEnabledCipherSuites())
{
if(!suite.contains("_DHE_"))
{
limited.add(suite);
}
}
((SSLSocket)s).setEnabledCipherSuites(limited.toArray(
new String[limited.size()]));
令人讨厌。
发布于 2015-07-10 15:44:48
您可以在jdk中完全禁用DHE,编辑jre/lib/security/java.security并确保禁用DHE,例如。喜欢
jdk.tls.disabledAlgorithms=SSLv3, DHE
。
发布于 2014-11-20 01:08:12
这是一个相当老的帖子,但是如果你使用Apache HTTPD,你可以限制DH大小。请参阅http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh
https://stackoverflow.com/questions/6851461
复制相似问题