☰

openssl 安全重新协商（不支持）

tag-icon • tag-icon openssl
openssl 安全重新协商（不支持）

我正在运行在 Ubuntu 14.04 LTS 服务器上实现的 Web 服务。我正在调试TLSv1 一段时间后连接断开在使用 的客户端openssl version 0.9.7m和使用 的服务器之间openssl 1.0.1f。我自己无法访问客户端，只能访问服务器和路由器。当我openssl s_server代替服务器运行时，我会看到secure renegotiation not supported客户端连接时的消息。重新协商不一定与连接问题有关，但我正在尝试理解重新协商。到目前为止，我还没有找到以下问题的答案：

  1. 重新协商的典型触发因素是什么？如果不支持安全协商，重新协商是否不安全？
  2. 重新协商是由客户端还是服务器代码发起的，或者 openssl 是否可以在某个点发起它？
  3. 有没有办法强制重新谈判openssl s_server和/或openssl s_client进行实验？

答案1

有四种类型的重新谈判可能的：

  • 客户端发起的安全重新协商
  • 客户端发起的不安全重新谈判
  • 服务器发起的安全重新协商
  • 服务器发起的不安全重新协商

自从发现了表演的可能性以来重新谈判攻击（CVE-2009-3555）存在的漏洞“在所有当前版本的 TLS 上”可以安全地假设，除非客户端和服务器都实现TLS 重新协商指示扩展。

OpenSSL 的第一个反应是禁用重新协商，并实施安全重新谈判在后续版本中。

根据定义，使用 0.9.7m 的客户端早于 CVE-2009-3555，不仅容易受到此攻击，而且无法执行安全重新协商。

至于什么可以触发重新协商，您可以在不同的 RFC 中进行跟踪：TLS v1.0，TLS v1.1，TLS v1.2。 不同的博客文章分析 CVE-2009-3555 还提供了有关发生这种情况的时间的详细信息。

至于是否可以出于s_client测试目的从子命令强制执行此操作，是的，这是手册页中有记录：

已连接命令
如果与 SSL 服务器建立了连接，则显示从服务器收到的任何数据，并将任何按键发送到服务器。当以交互方式使用时（即未指定 -quiet 或 -ign_eof），如果行以 R 开头，则将重新协商会话 [...]

也可以这样做以编程方式。

相关内容