Java 7并且无法生成DH密钥对 [英] Java 7 and Could not generate DH keypair

问题描述

我读了一篇关于当服务器发出长度超过1024位的密钥时出现无法生成DH密钥对错误的帖子。下载JCE无限量罐子应该可以解决这个问题。在测试环境中，我遇到了以下内容，对于同一个Web服务器，如果我使用Java 6，在执行https查询时没有出现任何错误，但是如果我使用Java 7则会得到无法生成DH密钥对。

I read a previous post regarding the error 'Could not generate DH keypair' fired when the server sents a key longer than 1024 bits. Downloading the JCE unlimited jars should fix this issue. In the test environment I have I encountered the following, for the same web server if I use Java 6 I don't get any errors when performing the https query but if I use Java 7 then I get 'Could not generate DH keypair'.

我尝试用JCE替换jar文件无限制，但仍然得到同样的错误。自2007年以来报告了该错误，但为什么它运行Java 6而不是Java 7？要下载的文件不是正确的吗？我从以前的帖子中获得了 Java：为什么SSL握手会给无法生成DH密钥对例外？。

I tried replacing the jar files for JCE unlimited but still get the same error. The bug is reported since 2007, but why does it run for Java 6 and not for Java 7? Are the files to download not the proper ones? I got the link from a previous post Java: Why does SSL handshake give 'Could not generate DH keypair' exception?.

此时我不知道该怎么做。如果我尝试加载BouncyCastle提供程序，我会得到一个ArrayOutOfIndex异常。我的服务器只允许DH算法，所以我不能使用上面帖子中建议的其他算法。

At this point I don't know what to do. If I try to load the BouncyCastle provider I get an ArrayOutOfIndex exception. My server only allows DH algorithm so I can't use another algorithm like suggested in the above post.

推荐答案

一些补充或澄清：

（Suncle）Java 7自7u09以来默认情况下使用更合理的密码组顺序，与7u04中看似随机的顺序不同。 （我在04和09之间没有测试。）此命令在DHE之前放置ECDHE和普通RSA（也称为akRSA），因此如果服务器支持ECDHE或RSA并且同意客户端首选项，则可以避免此问题。 （或ECDH固定，但实际上没有人使用它。）如果服务器坚持DHE（无论出于何种原因）并使用DH> 1024位，你仍然有问题。

(Suncle) Java 7 since 7u09 uses a more sensible consistent order of ciphersuites by default, unlike the seemingly random order in 7u04. (I don't have tests between 04 and 09.) This order puts ECDHE and plain-RSA (aka akRSA) before DHE, and thus avoids the problem if AND ONLY IF the server supports ECDHE or RSA and agrees to client preference. (Or ECDH-fixed, but practically nobody uses that.) If the server insists on DHE (for whatever reason) AND uses DH>1024 bits, you still have the problem.

如果提问者（或其他任何人）连接到真正需要整数DH（而不是ECDH或RSA）的服务器，那么在8之前使用Java的唯一方法是让服务器使用DH 1024位。哪种AFAWK在技术上可以安全使用多年，但由于NIST等重要机构禁止使用AFAWK（请参阅csrc.nist.gov上的Special Pub 800-57）。 （即使RSA 1024实际上还没有被破坏，但它可能很快就会被禁止。）

If the asker (or anyone else) connects to a server that truly requires integer-DH (and not ECDH or RSA), the only way to work with Java before 8 is to get the server to use DH 1024-bit. Which AFAWK is technically secure for a few more years, but with a thin margin it is prohibited by important authorities like NIST (see Special Pub 800-57 at csrc.nist.gov). (Even RSA 1024 isn't actually broken yet, but it probably will be soon and so is prohibited.)

无限强度政策与此问题无关，或者至少不是直接的，＃6851461的好答案并没有说出来。它不会改变SunJCE中对DH参数的限制，这被（错误地）视为标准问题而非强度问题。 （具体来说，它采用了以前对DSA正确的限制，并将它们应用于DH。）它确实启用了AES-256和SHA-2（仅适用于TLSv1.2）套件，并且给出了一个足够奇怪的首选项列表，将选择结果从DHE（失败）更改为非DHE（工作）。

The "unlimited strength policy" is not relevant to this problem, or at least not directly, and the good answers to #6851461 did not say it is. It does not change the restriction on DH parameters in SunJCE, which is (wrongly) treated as a standard issue not a strength issue. (Specifically it takes the restrictions that used to be correct for DSA, and applies them to DH.) It does enable AES-256 and SHA-2 (only for TLSv1.2) suites, and given a sufficiently strange preference list, that might change the selection result from DHE (fails) to non-DHE (works).

您不需要完全返回Java 6列表，您只需要通过DHE优先处理其他密钥交换，或者对一个顽固的服务器完全删除DHE。除非传统服务器绝对需要，否则你绝对不应该回到启用任何EXPORT或单DES套件;他们几年来一直没有安全，并且默认情况下仍然保持6个远远超过应有的时间。

You don't need to go entirely back to the Java 6 list, you just need to prioritize other key exchanges over DHE, or for a recalcitrant server drop DHE entirely. You definitely should NOT go back to enabling any EXPORT or single-DES suites, unless absolutely needed for a legacy server; they have been NOT SECURE for several years now, and remained enabled by default in 6 far longer than they should have.

这篇关于Java 7并且无法生成DH密钥对的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！