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 \系统\ CurrentControlSet \控制\ 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 ++代码(我已经玩过上面提到的注册表设置没有效果).

总而言之,我想知道以下事情之一是否会解决它以及如何实现它们:

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

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

编辑

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 握手确实成功了）。

感谢您的反馈，这是一次有趣但徒劳的搜索。活到老，学到老。