具有 TLSv1.2 的 Java 7 连接到 LDAPS 握手失败

Question

目前我使用的是 Java 7，无法连接到 LDAPS。我尝试使用下面的代码，但仍然无法连接:

SSLContext ctx = SSLContext.getInstance("TLSv1.2");
ctx.init(null, null, null);
SSLContext.setDefault(ctx);

下面是我从程序中得到的错误:

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, WRITE: TLSv1.2 Handshake, length = 221

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, READ: TLSv1.2 Alert, length = 2

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, RECV TLSv1 ALERT: fatal, handshake_failure

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, called closeSocket()

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

<小时/>

之后，我尝试运行协议(protocol)测试来检查支持的协议(protocol):

Supported Protocols: 5
  SSLv2Hello
  SSLv3
  TLSv1
  TLSv1.1
  TLSv1.2
Enabled Protocols: 1
  TLSv1

我添加了以下行以在 java.security 中禁用 TLSv1 并启用 TLSv1.2:

jdk.tls.disabledAlgorithms= SSLv3, SSLv2Hello, TLSv1, TLSv1.1

再次运行协议(protocol)测试，结果是:

Supported Protocols: 5
  SSLv2Hello
  SSLv3
  TLSv1
  TLSv1.1
  TLSv1.2
Enabled Protocols: 0

<小时/>

我已确认我的 LDAPS 服务器受支持并使用 TLSv1.2。我还在 Java 控制面板中启用了 TLS1.2，因为每当我尝试使用 TLSv1 时，都会导致 protocol_version 错误

<小时/>

我的问题是:

1. 什么是RECV TLSv1 ALERT:致命，handshake_failure？
2. 如何在支持的协议(protocol)中启用 TLSv1.2？
3. 编辑 Java 7 或 8 是否支持密码套件:ECDHE-ECDSA-AES256-GCM-SHA384？

我使用的是 Java 1.7_80。

Answer 1

1. What is RECV TLSv1 ALERT: fatal, handshake_failure ?

这意味着我们收到了(在 Java SSL/TLS 代码中，JSSE)来自服务器的警报，其严重性为致命，类型为握手失败。由于它是在发送一条握手消息后立即发生的，因此如果您没有从您发布的日志摘录中省略其他相关信息，我们可能会收到此警报以响应 ClientHello 消息，这是发送的第一条握手消息。

此处的“TLSv1”可能会产生误导。它是 SSLSocketImpl 对象中的一个变量，它被初始化为 TLSv1，并且在握手完成之前不会更新，因此此时它无法准确指示正在使用的协议(protocol)版本。前面的日志条目“READ:TLSv1.2 Alert，length = 2”确实显示收到的实际版本，并确认服务器至少正在尝试执行 TLS1.2 。

什么原因导致握手失败？很多很多的事情。实际上不可能从这个警报中判断出问题是什么。

• 您最好的选择是查看服务器日志并找出为什么它说它发送了警报。

• 最糟糕的选择是查看我们发送的 ClientHello——其中大部分应该在您发布的行之前已由 JSSE 记录——并考虑其中的所有内容，或者不在那里，服务器可能不喜欢其值或不存在，并尝试更改它们中的每一个。有些更改起来比较容易，有些则非常困难，因此这可能需要几个小时到几周的时间。

• 如果您有任何其他客户端成功连接到同一服务器，则中间选项是查看有效客户端和无效客户端之间的 ClientHello 差异，并考虑那些。作为这种情况的一种情况，如果您拥有或获得 OpenSSL，则可以使用命令行 openssl s_client 快速且相当简单地测试 SSL/TLS 握手的某些(但不是全部)变体。

你可能会猜到我推荐第一个。

2. How to enable TLSv1.2 in supported Protocols?

您不需要在支持中启用它；您需要在启用协议(protocol)中启用它，并且您已经这样做了。使用 SSLContext.getInstance("TLSv1.2") 是一种方法。在 Java 8 但不是(编辑)7 的免费 Oracle 更新中，使用 sysprop jdk.tls.client.protocols 是另一种方法。 (7u95 以上实现此 sysprop，但对于 7u80 以上的 Oracle 7 更新需要付费。如果 OpenJDK 在您的平台上可用，则通常是免费的。)在 SSLSocket 上调用 .setEnabledProtocols ，一旦拥有，就是另一种方式。

3. Edit Does Java 7 or 8 support cipher suite: ECDHE-ECDSA-AES256-GCM-SHA384? I'm using Java 1.7_80.

Oracle/Sun 和 OpenJDK 7 不支持 GCM 密码套件。或者确切地说，其中的标准 JSSE 提供程序没有，并且您没有提到任何有关更改提供程序的内容。 (IBM Java 使用不同的提供程序，我不了解它们，但它们大多使用不同的命名格式。)

Oracle 和 OpenJDK 8 支持 GCM 套件。但是，较旧的 Oracle 更新不支持 256 位 AES，除非您下载并安装“无限管辖权策略”文件；您可以找到很多其他有关此问题的问题。这个问题最近被修复了； 8u151/152 只需要文本编辑而不下载文件，8u161/162 及更高版本根本不需要任何更改。 Oracle 9 或任何 OpenJDK 也没有。