正如@Terry 所说，客户端建议，服务器选择. 有细节：

• 第一个客户端消息的通用格式 (the ClientHello) 表示支持的最高版本，并隐含地声称支持所有以前的版本——这不一定是真的。例如，如果客户端支持 TLS 1.2，那么它将指示“最大版本：1.2”。但是服务器可能会选择使用客户端不一定想要使用的先前版本（例如，TL​​S 1.0）。

• 现代客户已经养成了多次尝试的习惯。例如，客户端可能首先发送一条ClientHello声明“TLS 1.2”，如果某件事（任何事情）失败，它会再次尝试ClientHello声明“TLS 1.0”。客户端这样做是因为执行不力、不符合标准的 TLS 服务器可以执行 TLS 1.0 但拒绝ClientHello包含“TLS 1.2”的消息。

  一个有趣的结果是，即使客户端和服务器都支持较新的协议版本，主动攻击者也可以通过强制关闭初始连接来强制客户端和服务器使用旧版本（例如 TLS 1.0）。这称为“版本回滚攻击”。只要客户端和服务器从不接受使用绝对弱的协议版本（并且 TLS 1.0 仍然相当强大），这并不重要。然而，这意味着客户端和服务器不能保证他们正在使用“最佳”可能的协议版本，只要客户端实施这样的“重试”策略（如果客户端没有实施这样的“重试”，那么回滚攻击将被阻止，但某些网站将变得看似无法访问）。

• SSL 2.0的ClientHello消息具有非常独特的格式。当客户端希望同时支持 SSL 2.0 和更高版本时，它必须发送一个ClientHello遵循 SSL 2.0 格式的特殊文件，并指定“顺便说一下，我也知道 SSL 3.0 和 TLS 1.0”。这在RFC 2246 的附录 E 中进行了描述。现代 SSL 客户端（Web 浏览器）不再这样做（我认为 IE 6.0 仍然这样做，但不是 IE 7.0）。

  RFC 4346 (TLS 1.1) 规定此类 SSLv2 格式的ClientHello消息将在某个时候“逐步淘汰”，应避免使用。RFC 5246 (TLS 1.2) 更明确地指出客户端不应该支持 SSL 2.0，因此应该没有理由发送此类ClientHello消息。RFC 6176现在完全禁止SSL 2.0。

  现在 RFC 不是法律：您不会因为不支持任何特定的 RFC 而入狱。然而，RFC 仍然提供指导，因此以某种方式说明了近期（或远期）的情况。

在实践中：

• 大多数客户端只会发送 SSLv3+ClientHello消息，并且很乐意连接 SSL 3.0、TLS 1.0、TLS 1.1 或 TLS 1.2，具体取决于服务器似乎支持的内容（但是，由于“重试”策略，版本降级可以被主动攻击者强加）。
• 实际上，有些客户端不支持 SSL 3.0，需要 TLS 1.0。
• 同样，某些客户端不支持 TLS 1.1 或 1.2。近年来，Web 浏览器已经更新（在 BEAST 攻击造成的负面新闻之后），但非浏览器应用程序很少得到积极维护。
• 许多服务器仍然接受 SSLv2ClientHello格式，只要该ClientHello消息是伪装的 SSLv3+ ClientHello。
• 一些服务器，比如你的，仍然很乐意做一些 SSL 2.0。这不符合 RFC 6176，并且不受欢迎（相信“分级 SSL 服务器”的人会给你一个坏分数）。不过，这不是一个严重的安全问题，只要客户端实际上不支持 SSL 2.0。即使客户端支持 SSL 2.0，它也应该包含一些回滚预防技巧（在 RFC 2246 中描述），因此回滚到 SSL 2.0 应该不起作用。

ClientHello如果只是为了公共关系，您仍然希望停用服务器中的 SSL 2.0 支持（不一定是 SSLv2格式，而是实际的 SSL 2.0 支持）。

您应该阅读 TLS 握手过程。

简而言之，客户端（在这种情况下是浏览器）向ClientHello服务器发送消息。这包含它支持的最大 TLS 版本以及它支持的密码套件列表（按优先顺序排列）。然后服务器决定它想要用于 TLS 连接的 TLS 版本和密码套件，并通过回复一个ServerHello. 理想情况下，应该选择最高的 TLS 版本和最强的密码套件，但 TLS 规范并不能保证这一点。服务器可以自由使用客户端提供的列表中的任何内容。

当客户端想要使用 SSL/TLS 向服务器发送数据时，客户端必须首先通过握手来向服务器验证自己的身份。此握手以“ClientHello”开始，客户端向服务器发送它支持的 SSL 或 TLS 版本、支持的密码和其他会话数据。在旧版本的 SSL（版本 2）中，可以拦截此握手数据包并将支持的密码列表修改为仅包含弱密码。这不再可能，因为 SSLv3 在握手的最后部分使用散列，客户端和服务器都散列并比较发送和接收的消息。

所有现代浏览器都支持 SSLv3 到 TLSv1.2，但将使用服务器支持的最高版本。中间人不能直接修改握手中发送的任何数据包，但中间人可以拦截和丢弃某些数据包。通过诱使浏览器认为服务器不支持给定版本的 SSL/TLS，攻击者可以降级协商的版本。你可以通过访问Praetorian最近的帖子来了解它是如何完成的： Man-in-the-Middle TLS Protocol Downgrade Attack

为什么现在远离 SSLv3？

虽然 SSLv3 包含特殊的缓解措施来防止协议降级攻击，但它不一定是理想的协议。SSLv3 具有显着的加密差异，这可能会导致进一步证明为什么 TLSv1.2 应该成为当前标准的弱点。在我们的协议降级测试中，商定的加密和身份验证密码以及密钥交换机制存在显着差异。在上面的示例中，TLSv1.2 使用椭圆曲线加密 (ECC) 以及 AES 的计数器模式，而 SSLv3 使用较旧的 RC4 密码和 RSA。

有些人可能会问为什么这是必要的。在 2013 年的 Black Hat 演讲中，Alex Stamos 讨论了密码学的现状和未来。他认为，其中一个危险在于有可能在未来某个时候破解旧密码或密钥交换机制。就 RSA 而言，密码学家和数学家在因式分解问题上取得了重大进展。Diffie-Hellman (DH) 依赖于离散对数问题来解决密码安全问题，虽然不存在用于计算离散对数的有效算法，但离散对数算法的运行时间在过去一年中显着减少。正如 Stamos 所讨论的，一旦 RSA 或 DH 失败，代码签名就会中断，对 SSL/TLS 的攻击将变得非常普遍。

总之，对连接的主动攻击会导致密码安全性降低。客户端和服务器可以通过仅支持较新版本的 TLS 来防止这种情况发生。此外，客户端应该正确响应失败的握手。目前，许多浏览器选择互操作性而不是安全性，这使得协议降级攻击成为可能。这些变化将需要大量的时间和精力。浏览器需要重新实现它们处理握手的方式。在某些情况下，向后兼容性可能会中断。但是，最终我们将需要使用支持 ECC 的更新版本的 TLS。为什么不现在就推动，防止未来的攻击呢？