TLSv1握手失败

(声明:我不是一个安全专家的想象力,也不是一个窗口专家)

build立:

  • 服务器端:在Windows 2003服务器上的Java 1.6(已经添加到安全文件的bouncycastle)
  • 第三方客户端:与biztalk的Windows 2008服务器
  • 由于重新协商攻击而引入的所有重新协商系统属性在服务器端“启用”(我不知道安全)

理想情况下,我们希望在我们的最后解决这个问题,但如果有必要的话,可以向客户提出一个解决scheme。

客户端服务器必须通过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 )为了重现错误以便能够仔细检查,我用其他软件testing过

  • 在windows xp上用“https”select将在SSLv2中执行初始客户端握手,服务器将切换到TLSv1来回答,这个工作
  • 在windows xp上configuration为使用“TLSv1”进行初始握手的wfetch将以与biztalk服务器相同的方式失败
  • 在configuration了“https”的Windows 2008上,使用“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作为附加提供程序,但是无济于事。 我search了高和低,只发现可能是websphere支持TLSv1的Windows密码的参考,但没有办法下载一个独立的提供商来testing它。 JRE 1.7不支持我们在JVM上运行的软件,所以升级不是一种select(也许安全提供者可以安全降级?虽然我还没有find它的下载),但我发现没有办法添encryption码到窗口短的写作c + +代码(我已经玩过上面提到的registry设置没有效果)。

所以最后我想知道下面的一件事是否能解决这个问题,以及如何完成它们:

  • 添加一个供应商到jvm,可以与Windows提议的TLSv1密码一起使用
  • 以某种方式强制客户端在SSLv3(最好不是SSLv2)中进行初始握手,或者至less在TLSv1握手失败时重试
  • 以某种方式将用于TLSv1的JVM支持的密码添加到客户端窗口

任何其他解决scheme,当然也赞赏。

编辑

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

安装无限强度encryption策略文件。 我试图设置javax.net.debug=all并从控制台启动服务器,没有出现额外的输出。 我已经设置sun.security.ssl.allowUnsafeRenegotiation=true无济于事。

编辑2

事实certificate,我们正在使用的软件使用HTTP的自定义堆栈,而不是默认的。 虽然我不知道TLS请求的哪个部分触发了错误(看起来大部分TLSv1握手成功了),但似乎解决了问题。

感谢您的反馈意见,这是一个有趣的,如果徒劳的search。 活到老,学到老。

Solutions Collecting From Web of "TLSv1握手失败"

事实证明,我们正在使用的软件使用HTTP的自定义堆栈,而不是默认的。 虽然我不知道TLS请求的哪个部分触发了错误(看起来大部分TLSv1握手成功了),但似乎解决了问题。

感谢您的反馈意见,这是一个有趣的,如果徒劳的搜索。 活到老,学到老。

你可以阅读我的文章检测密码强度 (只是为了确保你正确安装了jce密码)。 在你的问题中,你说你安装了无限制的密码,但是你引用了128位和40位的密钥。 所以,我对你有什么感到困惑。 另外,您是否可以检查您尝试连接的SSL证书上的密码强度,并让我们知道它是什么以及算法是什么? 另外,请确保您的JDK策略文件具有允许无限强度的适当权限。

最后,你可以连接到一个“已知好的”SSL站点来正确验证你的客户端握手吗? (例如Gmail网页)