TLSv1握手失败

Question

（免责声明：对于安全专家而言，我并不是想象力，也不是Windows专家）

设定：

我们的终端上的
• 服务器：Windows 2003服务器上的java 1.6（已经在安全文件中添加了bouncycastle）
• 第三方客户端：带有biztalk的Windows 2008服务器
• 由于重新协商攻击而引入的所有重新协商系统属性都在服务器端“启用”（我知道不安全）

理想情况下，我们希望在最后修复此问题，但如有必要，可以向客户提出修复方法。

客户端服务器必须通过HTTPS连接连接到我们的服务器，但它始终失败，wireshark显示以下对话：

> TLSv1: Client Hello
< TLSv1: Alert (21): Unexpected Message

根据RFC（http://www.ietf.org/rfc/rfc2246.txt），警报（21）指的是一个失败的解密，从我在wireshark中看到的，没有一个密码提出的JRE 1.6实际支持客户端（根据http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites） 为了重现错误以便能够更接近地检查它，我测试了一些其他软件：

选择“https”的windows xp上的
• wfetch将在SSLv2中执行初始客户端握手，服务器将切换到TLSv1进行应答，此操作
配置为使用“TLSv1”进行初始握手的Windows XP上的
• wfetch将以与biztalk服务器相同的方式失败
配置为“https”的Windows 2008上的
• wfetch将使用“TLSv1”进行初始握手，并以与biztalk服务器相同的方式失败
• IE（在Windows XP上）最初会尝试使用相同的失败结果进行TLSv1握手，但会立即使用SSLv3再次尝试 （此时我认为所有微软软件都使用HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ Schannel中提供的中央配置）
• firefox在整个会话中使用SSLv3，所以没问题
• OpenSSL在SSLv2中执行初始握手，服务器在应答时切换到TLSv1，没问题
• OpenSSL也可以强制在TLSv1中进行初始握手，它提供了27个密码的列表（与基于Windows的软件提出的11个密码相反）并且可以毫无问题地连接

对于我未经训练的眼睛，这强化了这样一种观点，即不兼容的密码命题是Windows仅支持JVM不支持的密码套件的根本原因（对于TLSv1）。 我已经安装了充气城堡作为java.security文件中的附加提供程序无济于事。 我搜索了高低，只找到了一个参考，可能是websphere支持TLSv1的Windows密码，但无法下载独立的提供程序来测试它。 我们在JVM上运行的软件不支持JRE 1.7，因此升级不是一个选项（也许安全提供程序可以安全降级？但我还没有找到它的下载） 我发现没有办法在没有写c ++代码的情况下向Windows添加密码（我已经使用了上面提到的注册表设置而没有效果）。

总而言之，我想知道下列其中一件事是否会解决它以及如何完成它们：

• 向jvm添加一个提供程序，该提供程序可以使用Windows提出的TLSv1密码
• 以某种方式强制客户端在SSLv3中执行初始握手（最好不是SSLv2），或者至少在TLSv1握手失败时重试
• 以某种方式将TLSv1支持JVM的密码添加到客户端窗口

当然也赞赏任何其他解决方案。

修改

Java版本为Java version (64 bit): 1.6.0_19-b04。

建议的密码列表是：

• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

安装了无限强度加密策略文件。我试图设置javax.net.debug=all并从控制台启动服务器，没有出现其他输出。我设置sun.security.ssl.allowUnsafeRenegotiation=true无济于事。

编辑2

事实证明，我们使用的软件使用HTTP的自定义堆栈而不是默认堆栈。虽然我不确切地知道TLS请求的哪一部分触发了错误（看到大多数TLSv1握手确实成功），但是发布了修复程序似乎解决了这个问题。

感谢您的反馈，如果徒劳无功，那将是一件非常有趣的事情。生活和学习。

Answer 1

事实证明，我们使用的软件使用HTTP的自定义堆栈而不是默认堆栈。虽然我不确切地知道TLS请求的哪一部分触发了错误（看到大多数TLSv1握手确实成功），但是发布了修复程序似乎解决了这个问题。

感谢您的反馈，如果徒劳无功，那将是一件非常有趣的事情。生活和学习。

Answer 2

您可以在detecting cipher strength上阅读我的文章（只是为了确保您正确安装了jce密码）。在您的问题中，您说您安装了无限密码，但随后您引用了128位和40位密钥。所以，我对你所拥有的东西感到困惑。此外，您是否可以检查您尝试连接的SSL证书的密码强度，并告诉我们它是什么以及算法是什么？另外，请确保您的JDK策略文件具有允许无限强度的适当权限。

最后，您是否可以连接到“已知良好”的SSL站点来验证您的客户端握手是否正确？ （例如Gmail网站）