启用SSLv2 ClientHello支持安全吗？

Question

在贵宾犬攻击之后，许多网站已经放弃了对SSLv3的支持。但截至2015年5月，一些仍在使用中的客户端仍在使用SSLv2 ClientHello消息发起握手。例如，OpenSSL0.9.8附带Mac 10.10，Java 6至少在Mac上仍然常用。

甲骨文建议认为使用JSSE终止SSL的服务器保持启用SSLv2Hello伪协议，这反过来又允许SSLv2 ClientHello握手，以便与此类客户端向后兼容。(请参阅表行“使用JSSE APIs Server的开发人员”)。

虽然使用SSLv2 ClientHello的客户端容易受到协议降级攻击，但对于使用后期握手版本的客户端也是如此，除非客户端和服务器都支持TLS_FALLBACK_SCSV。而且，只要服务器禁用了SSLv2和SSLv3，握手就不能以低于TLSv1的协议完成。我怀疑支持TLSv1.1或更高版本的客户端可能不会使用SSLv2 ClientHello，因此在我看来，这是一种合理的配置。

我是否遗漏了任何已知的攻击向量，这会使启用SSLv2 ClientHello支持变得不明智？

Answer 1

根据最近的溺水脆弱性，现在至关重要的是在任何服务器上禁用SSLv2协议，这样攻击者就有可能握手。它现在不仅被认为是不安全的，而且是高度关键的，因为它可以使用相同的证书危及其他服务器。更多信息这里和这里。

SSLv2Hello对它是安全的，并且可以使用它，因为它实际上并不是进行完全握手，而是通过协商进行握手的协议。

Answer 2

注意: Java/JSSE没有实现真正的SSLv2 (只有hello)，所以不需要禁用它。正如链接文章所述，最近的更新默认禁用SSLv3，但您可以重新启用它；尽量不启用它。

攻击:我不认为有来自v2Hello的任何直接攻击，但可能存在功能限制。首先，它阻止了扩展的使用，其中一些扩展现在非常重要或至关重要:虚拟主机或类似的主机可能需要使用SNI；为了正确地协商首选的甚至可用的密码，可能需要使用ECcurves和sigalgs。(在随后的任何握手中都需要Renego_info，但这应该会提高格式，尽管我还没有检查；在初始握手中，is就足够了，而且似乎基本上是首选的。)

客户端: OpenSSL 0.9.8命令行s_client默认为v2hello，但-no_ssl2或更具体的-ssl3或-tls1修复了它；使用任何OpenSSL的应用程序必须选择特定的协议，或者使用(现在命名不当) "v23“方法来支持可能是显式的范围，除非在1.0.0+ "v23”中，如果密码列表不包括任何SSLv2密码，则自动取消SSLv2协议和v2hello格式的选择。如果应用程序硬编码，可以禁用Java6 client v2hello，或者可以配置它，或者可以更改源代码--或者至少是其中的相关部分(S)，因为许多应用程序大多是库加胶水。