![openssl 安全重新协商(不支持)](https://linux22.com/image/695790/openssl%20%E5%AE%89%E5%85%A8%E9%87%8D%E6%96%B0%E5%8D%8F%E5%95%86%EF%BC%88%E4%B8%8D%E6%94%AF%E6%8C%81%EF%BC%89.png)
我正在运行在 Ubuntu 14.04 LTS 服务器上实现的 Web 服务。我正在调试TLSv1
一段时间后连接断开在使用 的客户端openssl version 0.9.7m
和使用 的服务器之间openssl 1.0.1f
。我自己无法访问客户端,只能访问服务器和路由器。当我openssl s_server
代替服务器运行时,我会看到secure renegotiation not supported
客户端连接时的消息。重新协商不一定与连接问题有关,但我正在尝试理解重新协商。到目前为止,我还没有找到以下问题的答案:
- 重新协商的典型触发因素是什么?如果不支持安全协商,重新协商是否不安全?
- 重新协商是由客户端还是服务器代码发起的,或者 openssl 是否可以在某个点发起它?
- 有没有办法强制重新谈判
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 开头,则将重新协商会话 [...]
也可以这样做以编程方式。