握手失败(40)和TLS_EMPTY_RENEGOTIATION_INFO_SCSV [英] handshake failure(40) and TLS_EMPTY_RENEGOTIATION_INFO_SCSV

问题描述

jBOSS上安装的客户端正在尝试访问在DataPower xi50v6.0.0.2设备上配置的安全网站. SSL握手连接失败.

A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.

我在DataPower处捕获了一个数据包，并观察到Description:Handshake failure(40)导致SSL握手失败.

I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).

但是，我发现在Client Hello步骤中，仅指定了一个密码套件:TLS_EMPTY_RENEGOTIATION_INFO_SCSV. 所使用的TLS协议(根据数据包捕获)为TLS1.1.这个密码套件会出现问题吗? 在DataPower系统日志中，我可以看到以下错误: Request processing failed: Connection terminated before request headers read because of the connection error occurs

However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV. The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem? In the DataPower system logs I can see below error: Request processing failed: Connection terminated before request headers read because of the connection error occurs

更新: 客户端应用程序正在jBOSS7上运行.我已要求jBOSS管理员在jBOSS端检查配置.我以某种方式可以访问安装了jBOSS实例的服务器，并检查了配置ssl的domain.xml.可以在domain.xml的确切位置找到与密码套件相关的配置?

Update: The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?

推荐答案

我观察到，仅指定了一个密码套件，即:TLS_EMPTY_RENEGOTIATION_INFO_SCSV

I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV

这不是真正的密码.如果未指定其他密码，则客户端根本不提供任何密码，这意味着找不到共享密码，因此握手将失败.客户端看起来像是越野车.原因可能是通过禁用所有SSL3.0密码来抵抗POODLE攻击的失败尝试，实际上禁用了TLS1 1.0和TLS 1.1的所有密码.

This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.

这篇关于握手失败(40)和TLS_EMPTY_RENEGOTIATION_INFO_SCSV的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！