Java 6 ECDHE 密码套件支持
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/27323858/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java 6 ECDHE Cipher Suite Support
提问by chashi
The Java Cryptography Architecture Standard Algorithm Name Documentationpage for Java 6 lists ECDHE cipher suites. Thus I would expect they are supported in Java 6. Yet neither OOTB Java 6 nor the addition of the JCE Unlimited Strength policy files is enabling them.
Java 6的Java 密码体系结构标准算法名称文档页面列出了 ECDHE 密码套件。因此，我希望 Java 6 支持它们。然而，OOTB Java 6 和 JCE Unlimited Strength 策略文件的添加都无法启用它们。
The book Bulletproof SSL and TLSalso indicates Java 6 supports ECDHE, with a caveat:
Bulletproof SSL and TLS一书也表明 Java 6 支持 ECDHE，但有一个警告：
Enable and prioritize ECDHE suites on the server. Java 6 and 7 clients support these, and will happily use them. (But do note that with Java 6 you must switch to using the v3 handshake in order to utilize ECDHE suites at the client level.)
在服务器上启用 ECDHE 套件并确定其优先级。Java 6 和 7 客户端支持这些，并且很乐意使用它们。（但请注意，对于 Java 6，您必须切换到使用 v3 握手，以便在客户端级别使用 ECDHE 套件。）
I'm assuming by v3 handshake he means SSLv3? I haven't tried it but even if this works, SSLv3 is not a viable option due to the POODLE vulnerability.
我假设通过 v3 握手他的意思是 SSLv3？我还没有尝试过，但即使这有效，由于 POODLE 漏洞，SSLv3 也不是一个可行的选择。
What am I missing?
我错过了什么？
回答by dave_thompson_085
The SSL/TLS implementation "JSSE" in Java 1.6 and later supports ECDHE suites IF there is an available (JCE) providerfor needed ECC primitives. Java 1.6 OOTB does NOTinclude such an ECC provider, but you can add one. Java 7 and 8 doinclude SunECC provider.
Java 1.6 及更高版本中的 SSL/TLS 实现“JSSE”支持 ECDHE 套件，前提是有一个可用的 (JCE) 提供程序来提供所需的 ECC 原语。Java 1.6 OOTB 不包含这样的 ECC 提供程序，但您可以添加一个。Java 7 和 8 确实包含 SunECC 提供程序。
This seems to be a hot topic today. See also https://security.stackexchange.com/questions/74270/which-forward-secrecy-cipher-suites-are-supported-for-tls1-0-protocolsand https://superuser.com/questions/848698/testing-cipher-suite-using-openssl-for-tomcat-server-is-resulting-in-wrong-manne(which, suprisingly to me, was migrated from security).
这似乎是今天的热门话题。另见https://security.stackexchange.com/questions/74270/which-forward-secrecy-cipher-suites-are-supported-for-tls1-0-protocols和https://superuser.com/questions/848698/ testing-cipher-suite-using-openssl-for-tomcat-server-is-resulting-in-wrong-manne（令我惊讶的是，它是从安全性迁移而来的）。
Ristic's book undoubtedly means the v3 formatClientHello. There was a major format change between SSL2 and SSL3, and SSL2 ClientHello can't represent the data (particularly extensions) for ECC. All versions of TLS (to date) use the same formatas SSL3, with (importantly) different contents. In the early oughties SSL clients often used SSL2 formatClientHello but with contentallowing upgrade to SSL3 and even TLS1.0 in order to succeed against both/all servers, because many SSL2 were still in use.
Ristic 的书无疑意味着 v3格式ClientHello。SSL2 和 SSL3 之间的格式发生了重大变化，并且 SSL2 ClientHello 无法表示 ECC 的数据（尤其是扩展）。所有版本的 TLS（迄今为止）都使用与SSL3相同的格式，具有（重要的）不同的内容。在早期，SSL 客户端经常使用 SSL2格式ClientHello，但内容允许升级到 SSL3 甚至 TLS1.0，以便成功对抗所有服务器，因为许多 SSL2 仍在使用中。
Java 1.6 client circa 2006 was transitional -- by default it uses SSL2 formatspecifying versionsup to TLS1.0, but if the server agrees to versionSSL2 and not higher, the client aborts with an exception saying in effect "SSL2 is not secure". This is controlled by a pseudo-protocol string SSLv2Hello, so on Java 1.6 client you should .setEnabledProtocolsto remove/exclude that.
大约 2006 年的 Java 1.6 客户端是过渡性的——默认情况下，它使用 SSL2格式指定最高 TLS1.0 的版本，但如果服务器同意 SSL2版本而不是更高版本，则客户端会中止并出现异常，实际上是“SSL2 不安全” . 这是由伪协议 string 控制的SSLv2Hello，因此在 Java 1.6 客户端上，您应该.setEnabledProtocols删除/排除它。
Java 7 and 8 still implement SSLv2Hellobut no longer enable it by default, so v3 format is used by default, or as long as you specify protocols to be (all) SSL3 or better. 7 and 8 also implement TLS1.1 and 1.2 which 6 did not, although only 8 enables them in client by default. You should only specify SSLv2Helloif you are connecting to way-old SSL2-only servers -- which of course you should try very hard not to do at all.
Java 7 和 8 仍然实现SSLv2Hello但不再默认启用它，因此默认使用 v3 格式，或者只要您指定协议为（全部）SSL3 或更好。7 和 8 还实现了 TLS1.1 和 1.2，而 6 没有，尽管默认情况下只有 8 在客户端启用它们。您应该只指定SSLv2Hello是否要连接到老式的 SSL2-only 服务器——当然，您应该非常努力地不这样做。
回答by Christer B
The answer that dave_thompson_085 provided is correct and helped me, but I would like to add some clarification. As he states, the available algorithms depend on the JCE provider. I have Sun/Oracle Java 6 release 45 on Centos 5.4, which has no support for ECDHE OOTB.
dave_thompson_085 提供的答案是正确的并且对我有帮助，但我想补充一些说明。正如他所说，可用的算法取决于 JCE 提供者。我在 Centos 5.4 上安装了 Sun/Oracle Java 6 版本 45，它不支持 ECDHE OOTB。
So I need to add an additional JCE provider and Bouncy Castle (bouncycastle.org) is one. Follow the instructions here https://www.bouncycastle.org/specifications.html#installThis extends the support to e.g. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
所以我需要添加一个额外的 JCE 提供者，而 Bouncy Castle (bouncycastle.org) 就是其中之一。按照此处的说明进行操作https://www.bouncycastle.org/specifications.html#install这将支持扩展到例如 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
An alternative is to use the sun.security.pkcs11.SunPKCS11 provider bundled with the Hotspot JRE. You need a ${java.home}/lib/security/nss.cfg with the following content:
另一种方法是使用与 Hotspot JRE 捆绑在一起的 sun.security.pkcs11.SunPKCS11 提供程序。您需要一个包含以下内容的 ${java.home}/lib/security/nss.cfg：
name = NSS
nssDbMode = noDb
attributes = compatibility
This will utilize libnss3, which may provide the necessary algorithms through the native OS library. This has been verified on Ubuntu 12.04, but may also work in other distros. It does not work on Centos 5.4, since RH/Centos 5 is knownto have limited Elliptic Curve support.
这将使用 libnss3，它可以通过本机操作系统库提供必要的算法。这已在 Ubuntu 12.04 上得到验证，但也可用于其他发行版。它不适用于 Centos 5.4，因为已知RH/Centos 5对椭圆曲线的支持有限。
回答by Will Sargent
You need to turn on -Djavax.net.debug=all and see what's going on here, and provide sample code and logs.
您需要打开 -Djavax.net.debug=all 并查看这里发生了什么，并提供示例代码和日志。
In 1.6, SunJSSE supports TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
在 1.6 中，SunJSSE 支持 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA：http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
So you should set your SSLContext with that as the enabled protocol. Look at http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLContextfor details. You also need to swap your enabled protocols so that 1.2 is enabled and in the lead.
因此，您应该将 SSLContext 设置为启用的协议。有关详细信息，请查看http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLContext。您还需要交换启用的协议，以便启用 1.2 并处于领先地位。
Also see
另见
