使用 openssl 检查服务器安全协议答案

【问题标题】：Check Server security protocol using openssl使用 openssl 检查服务器安全协议
【发布时间】：2014-12-03 17:41:12
【问题描述】：

我有一个框架应用程序，它根据使用方式连接到不同的服务器。对于 https 连接，使用 openssl。我的问题是，我需要知道我要连接的服务器是使用 SSL 还是 TLS，这样我才能创建正确的 SSL 上下文。目前，如果我使用错误的上下文尝试建立连接超时。

对于 TLS 我使用：

SSL_CTX *sslContext = SSL_CTX_new(TLSv1_client_method());

对于 SSL，我使用：

SSL_CTX *sslContext = SSL_CTX_new(SSLv23_client_method());

那么有没有办法在建立连接之前知道服务器正在运行哪个协议？

编辑：据我所知，它现在应该可以工作，因为SSLv23_client_method() 还包含 TLS 协议。所以问题是为什么不呢？一种客户端方法超时但另一种客户端方法超时的原因可能是什么？

【问题讨论】：

“那么问题是为什么不呢？” - 请提供服务器名称或 URL 以供我们测试。否则，我们没有足够的信息来帮助您。（请不要在事后更改问题。提出一个新问题）。
我自己没有访问服务器的权限。但是，我会检查是否允许我与您共享 IP / 主机名。这可能需要几天时间。
好的，如果您不想公开分享，请发送电子邮件至 noloader，gmail 帐户。

标签： c++ ssl openssl

【解决方案1】：

For SSL I use:
SSL_CTX *sslContext = SSL_CTX_new(SSLv23_client_method());

TLS 只是以前 SSL 协议的当前名称，即 TLS1.0 实际上是 SSL3.1 等。SSLv23_client_method 实际上是建立 SSL/TLS 连接的最兼容的方式，并将使用可用的最佳协议。这意味着如果服务器支持它，它也会创建 TLS1.2 连接。参见documentation of SSL_CTX_new：

SSLv23_method(void)、SSLv23_server_method(void)、SSLv23_client_method(void)

使用这些方法建立的 TLS/SSL 连接可以理解 SSLv2、SSLv3、TLSv1、TLSv1.1 和 TLSv1.2 协议。

...客户端将发送包含扩展的 TLSv1 客户端问候消息，并表明它也理解 TLSv1.1、TLSv1.2 并允许回退到 SSLv3。服务器将支持 SSLv3、TLSv1、TLSv1.1 和 TLSv1.2 协议。考虑到兼容性时，这是最佳选择。

您不需要的任何协议（如 SSL3.0）都可以使用SSL_OP_NO_SSLv3 等和SSL_CTX_set_options 禁用。

目前如果我使用错误的上下文尝试建立连接会超时。

那么要么服务器坏了，要么你的代码坏了。如果服务器与它不理解的协议建立连接，它应该返回“未知协议”警报。其他服务器只需关闭连接。超时通常只会在服务器损坏或中间盒（如旧的F5 Big IP load balancer）时发生。

【讨论】：

看来你是对的。感谢您对文档的提示。这必须是服务器端的问题。不幸的是，我无法直接访问服务器，因此我不知道如何获得有关该错误的更多信息。

【解决方案2】：

那么有没有办法在建立连接之前知道服务器正在运行哪个协议？

没有。但是您现在应该假定它的“TLS 1.0 及更高版本”。

正如 Steffen 所指出的，您使用 SSLv23_method 和上下文选项来实现“TLS 1.0 及更高版本”。这是完整的代码。您可以在客户端或服务器中使用它：

const SSL_METHOD* method = SSLv23_method();
if(method == NULL) handleFailure();

SSL_CTX* ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();

const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);

现在，这里有一个不太明显的隐含假设；这个假设是错误的。该假设是存在“TLS min”和“TLS max”版本。

发生的情况是存在承载协议有效负载的底层 SSL/TLS 记录层。 TLS 记录层独立于协议层，有自己的版本。人们将 TLS 记录层版本解释为“TLS min”版本；协议版本为“TLS max”版本。大多数客户端服务器、站点和服务都以这种方式使用它。

但是，IETF 并未以这种方式指定它，浏览器也不会以这种方式使用它。因此，我们最近收到了TLS Fallback Signaling Cipher Suite Value (SCSV)。

浏览器是正确的。这是它应该如何完成的：

尝试 TLS 1.2，使用 Fallback Signaling 检测降级攻击
如果 TLS 1.2 失败，则尝试 TLS 1.1，使用 Fallback Signaling 检测降级攻击
如果 TLS 1.1 失败，则尝试 TLS 1.0，使用 Fallback Signaling 检测降级攻击

许多人在 TLS 1.0 失败后放弃了。一些用户代理可能会继续使用 SSLv3。

为什么 IETF 没有向我们提供“TLS min”和“TLS max”？这仍然是个谜。我认为给出的有效论点是“假设客户端想要使用 TLS 1.0、1.2 和 1.3，而不是 1.1”。我不知道有谁会放弃这样的协议版本，所以它对我来说只是个稻草人。（这是我想知道执法部门或国家利益（如 NSA）是否在篡改标准的时候之一。

该问题最近再次在 TLS 工作组中提出。来自TLS: prohibit <1.2 support on 1.3+ servers (but allow clients)（2015 年 5 月 21 日）：

现在可能是为 TLS 1.3 添加 (3) 的好时机：拥有一个客户端指定他们愿意使用的最低 TLS 版本，以及他们希望使用的最强大的 TLS。而MAC还是从它派生出来的吧不可篡改或降级。

您仍然可以提供 TLS 记录层版本，并且您可以保持它未经过 MAC 处理，以便它可以被篡改以导致泄露或崩溃:)

实际上，记录层和客户端中的版本就是这样正在使用协议。它阻止了浏览器和那些愚蠢的舞蹈其他用户代理无需 TLS Fallback SCSV 即可执行。

如果 IETF 的部分使命是记录现有实践，那么 IETF 并未履行其使命。

【讨论】：