TLSv1 握手失败
（免责声明：我绝对不是安全专家，也不是Windows专家）
设置：
- 我们端的服务器：Windows 2003服务器上的java 1.6（已经将bouncycastle添加到安全文件中）
- 第三方客户端：Windows 2008带有 biztalk 的服务器
- 由于重新协商攻击而引入的所有重新协商系统属性都在服务器端“启用”（我知道不安全）
理想情况下，我们希望在最后修复此问题，但是如有必要，可以向客户提出修复建议。
客户端服务器必须通过 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/指南/security/SunProviders.html#SupportedCipherSuites） 为了重现该错误以便能够更仔细地检查它，我使用其他一些软件进行了测试：
- 在 Windows XP 上选择“https”的 wfetch 将在 SSLv2 中执行初始客户端握手，服务器将切换到 TLSv1 来应答，这 在 Windows XP 上配置为使用“TLSv1”进行初始握手的wfetch
- 将会失败，就像
- Windows 2008 上配置为“https”的 biztalk 服务器 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 文件中安装了 bouncy castle 作为附加提供程序，但无济于事。 我到处搜索，只找到了一个参考，也许 websphere 支持 TLSv1 的 Windows 密码，但无法下载独立的提供程序来测试它。 我们在 JVM 上运行的软件不支持 JRE 1.7，因此无法选择升级（也许可以安全地降级安全提供程序？不过我还没有找到它的下载） 我发现除了编写 C++ 代码之外，没有其他方法可以向 Windows 添加密码（我已经尝试过上述注册表设置，但没有效果）。
因此，总而言之，我想知道以下其中一项是否可以修复它以及如何完成它们：
- 向 jvm 添加一个提供程序，该提供程序可以与 Windows 提出的 TLSv1 密码一起使用，
- 以某种方式强制客户端在SSLv3（最好不是 SSLv2）或至少在 TLSv1 握手失败时重试
- 以某种方式将 JVM 支持的 TLSv1 密码添加到客户端窗口
当然也欢迎任何其他解决方案。
编辑
Java版本是Java版本（64位）：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 握手确实成功了）。
感谢您的反馈，这是一次有趣但徒劳的搜索。生活和学习。
(Disclaimer: I am by no stretch of the imagination a security expert nor a windows expert for that matter)
Setup:
- server on our end: java 1.6 (already added bouncycastle to the security file) on windows 2003 server
- third party client: windows 2008 server with biztalk
- all renegotiation system properties introduced due to the renegotiation attack are "enabled" on the server side (not safe I know)
Ideally we want to fix this at our end but it is possible to propose a fix to the client if necessary.
The client server has to connect to our server over a HTTPS connection but it always fails, wireshark shows the following conversation:
> TLSv1: Client Hello
< TLSv1: Alert (21): Unexpected Message
As per the RFC (http://www.ietf.org/rfc/rfc2246.txt) the alert(21) refers to a failed decryption and from what I can see in wireshark, none of the ciphers proposed by the client are actually supported by JRE 1.6 (as per http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites)
In an effort to reproduce the error to be able to examine it closer, I tested with some other software:
- wfetch on windows xp with "https" selected will perform the initial client handshake in SSLv2, the server will switch to TLSv1 to answer, this works
- wfetch on windows xp with configured to use "TLSv1" for the initial handshake will fail in the same way as the biztalk server
- wfetch on windows 2008 with configured "https" will use "TLSv1" for the initial handshake and fail in the same way as the biztalk server
- IE (on windows xp) will initially try a TLSv1 handshake with the same failed result but immediately tries again using SSLv3 which works
(at this point I figure all microsoft software uses a central configuration available at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel) - firefox uses SSLv3 for the entire conversation, so no problem there
- OpenSSL performs an initial handshake in SSLv2, and the server switches to TLSv1 when it answers, no problem there
- OpenSSL can be forced to do the initial handshake in TLSv1 as well, it offers a list of 27 ciphers (as opposed to the 11 ciphers proposed by windows-based software) and can connect without a problem
To my untrained eye this reinforces the idea that an incompatible cipher proposition is the root cause where windows only supports cipher suites that are not supported by JVM (for TLSv1).
I have installed bouncy castle as an additional provider in the java.security file to no avail.
I have searched high and low and only found a reference that maybe websphere supports the windows ciphers for TLSv1 but no way of downloading a standalone provider to test it.
JRE 1.7 is not supported by the software we run on our JVM, so upgrading is not an option (perhaps the security provider can be downgraded safely? I haven't found a download for it yet though)
I have found no way to add a cipher to windows short of writing c++ code (I've played around with the above mentioned registry settings without effect).
So in conclusion I wonder if one of the following things would fix it and how they should be accomplished:
- add a provider to the jvm that can work with the ciphers for TLSv1 that are proposed by windows
- somehow force the client to do the initial handshake in SSLv3 (preferably not SSLv2) or at least retry if the TLSv1 handshake fails
- somehow add a JVM-supported cipher for TLSv1 to the client windows
Any other solutions are of course also appreciated.
EDIT
The Java version is Java version (64 bit): 1.6.0_19-b04.
The list of proposed ciphers is:
- 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
The unlimited strength cryptography policy files are installed. I have tried to set javax.net.debug=all and started the server from the console, no additional output appeared. I have set sun.security.ssl.allowUnsafeRenegotiation=true to no avail.
EDIT 2
It turns out the software we are using uses a custom stack for HTTPs instead of the default. A fix was issued which seems to solve the problem though I don't know exactly which part of the TLS request triggered the error (seeing as most TLSv1 handshakes did succeed).
Thanks for the feedback, it has been an interesting if futile search. Live and learn.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以阅读我的文章 检测密码强度（只是为了确保您正确安装了 jce 密码）。在您的问题中，您说您安装了无限的密码，但随后您引用了 128 和 40 位密钥。所以，我对你所拥有的感到困惑。另外，您能否检查您尝试连接的 SSL 证书的密码强度，并让我们知道它是什么以及算法是什么？另外，请确保您的 JDK 策略文件具有允许无限强度的适当权限。
最后，您能否连接到“已知良好”的 SSL 站点来正确验证您的客户端握手？ （以 Gmail 网页为例）
You could read my article on detecting cipher strength (just to make sure you installed the jce ciphers correctly) . In your question you say you installed unlimited ciphers but then you reference 128 and 40-bit keys. So, I am confused by what you have. Also, could you check the cipher strength on the SSL cert you are trying to connect to and let us know what it is and what the algorithm is? Also, make sure your policy file for JDK has the proper rights to allow unlimited strength.
Finally, can you connect to a "known good" SSL site to verify your client handshakes correctly? (Gmail web for example)
事实证明，我们使用的软件使用自定义 HTTP 堆栈，而不是默认堆栈。已发布修复程序，似乎解决了问题，但我不知道 TLS 请求的哪一部分触发了错误（看来大多数 TLSv1 握手确实成功了）。
感谢您的反馈，这是一次有趣但徒劳的搜索。生活和学习。
It turns out the software we are using uses a custom stack for HTTPs instead of the default. A fix was issued which seems to solve the problem though I don't know exactly which part of the TLS request triggered the error (seeing as most TLSv1 handshakes did succeed).
Thanks for the feedback, it has been an interesting if futile search. Live and learn.