关于行业公认的做法：

（来自http://www.rapid7.com/vulndb/lookup/sslv2-and-up-enabled）

“SSLv2 已被弃用，不再推荐使用。请注意，SSLv2 和 SSLv3 都不符合美国 FIPS 140-2 标准，该标准管理用于联邦信息系统的加密模块。只有较新的 TLS（传输层安全）协议符合 FIPS 140 -2 要求。此外，主机上存在仅 SSLv2 服务被 PCI（支付卡行业）数据安全标准视为失败。请注意，无论远程服务器是否支持 SSLv2，都会报告此漏洞还支持 TLS 或 SSLv3。”

关于您问题的最后一部分：不，代理通常不能保护一堆客户端站点免受 SSLv2 问题的影响。在SSL/TLS中，事情大多是这样的：

• 客户端发送一条ClientHello消息，其中说明它接受的最大协议版本号（因此，TLS 1.0 被宣布为“SSL 3.1”）。
• 服务器以ServerHello指定实际使用的协议版本的消息进行响应。
• 客户端和服务器交换一些其他消息，其中包含一些重要的密码学，产生一个“共享秘密”，然后用作加密和解密数据的密钥。
• 在握手结束时，就在发送和接收实际应用程序数据之前，发送了两条Finished消息（一条由客户端，一条由服务器），其中包含一些数据，这些数据是根据先前交换的消息计算得出的哈希值。服务器（resp.client）在接收到Finished来自客户端（resp.server）的消息后，重新计算预期的哈希值；在不匹配时，它会关闭连接。

现在让我们看看有代理时会发生什么。HTTP 代理应该处理 HTTP 请求和响应。SSL 不是请求-响应协议；它期望并提供双向隧道。因此在 HTTP 中设计了一些特殊的东西（在RFC 2817，第 5 节中指定）：客户端向CONNECT代理发送命令，指示它在两个方向上转发所有后续数据字节。

因此，即使存在 HTTP 代理，加密仍然发生在客户端和服务器之间。代理将看到握手消息，但是（这是重要的一点）它不能修改它们，因为这会弄乱Finished消息的哈希计算：客户端和服务器不会看到完全相同的握手消息，它们会计算不同的哈希，并且Finished消息会不匹配。特别是，如果客户端发送一个ClientHello声明它支持 SSLv2（即，ClientHello它使用 SSLv2 格式，同时仍然写“我支持高达 3.1”），代理无法更改它。

注意：在 SSLv2 协议中，握手没有Finished消息。因此，可以拦截两个方向（代理处于理想位置）的攻击者可以劫持ClientHelloSSLv2 格式的 a 并将“支持的最大版本”从 3.1 更改为 2.0。这可以强制支持 SSLv2 的客户端和服务器使用 SSLv2，即使它们都支持 SSLv3+。这称为“版本回滚攻击”。TLS 1.0 规范包括一个阻止攻击的解决方法（第 E.2 节）。

上面我写的是“正常”。在某些情况下，代理可以做一件时髦的事情。即，代理以真正的中间人方式“攻击”连接。这要求代理在现场生成一个伪造的服务器证书，并带有一个嵌入的 ad hoc CA；相应的根证书必须已安装在客户端中（即不用担心，您的 ISP 代理无法强制您这样做）。

存在这样的劫持代理；这种诡计被用来对交换的内容应用激进的过滤技术（它也有点不受欢迎，因为它依赖于稍微破坏 SSL 安全性的基础）。劫持代理理论上可以与客户端执行 SSLv2，并与目标服务器执行 SSLv3+，实际上是“保护多个客户端免受 SSLv2 攻击”。

在实践中，懂 SSLv2 而不懂 SSLv3 的软件非常少见；对于 Web 浏览器，这让我们回到了 90 年代中期。所以，一般来说，你可以从你的所有配置中完全禁止 SSLv2，一切都会很好。

向后兼容性是我们应该要求放弃的那些事情之一。每家公司的每个 CISO/CSO 都应该告诉产品供应商，如果他们支持 SSL 2.0、WEP 等，他们就死定了。

大概。这就是 Ubuntu 发行版 2 年前开始做的事情，现在正在完成。查看一些问题：https ://wiki.ubuntu.com/MigrateOffSSL2 并查看邮件列表中最近的讨论：https ://lists.ubuntu.com/archives/ubuntu-devel/2010-July/031010.html