http 持久连接和 ssl 会话答案

【问题标题】：http persistent connection and ssl sessionhttp 持久连接和 ssl 会话
【发布时间】：2011-06-09 23:52:34
【问题描述】：

HTTP 是一种应用程序协议，可以关闭和重新打开底层 TCP 连接而不影响 HTTP 应用程序（性能除外）。
通过使用 HTTP1.1，我们使用持久连接，但服务器或客户端仍然可以随时关闭连接。
为安全起见，HTTP 通过 SSL/TLS 使用 TCP。
我的理解是 SSL 的行为很像一个应用程序，至少 TCP “查看” SSL 是这样的。
我的问题是，如果底层 TCP 套接字在安全连接建立后的某个时间点关闭，这是否意味着 SSL 会话无效并且各方应该重新开始 ssl 握手？
还是底层 TCP 连接与 TLS 会话无关？

谢谢！

【问题讨论】：

标签： http tomcat https ssl

【解决方案1】：

这是否意味着 SSL 会话无效，各方应重新开始 ssl 握手？

是的，SSL/TLS 会话已经结束，必须重新建立握手。 TLS 包括恢复会话的机制（仍然会执行一些操作，但少于完全握手），但并非所有应用程序都支持它。

有关恢复的技术细节，请参阅http://ietf.org/rfc/rfc2246.txt，F.1.4。

【讨论】：

@Eugene：握手后，SSL对等部分具有建立安全通道（加密/解密）所需的信息，因为安全细节已经交换（算法等）。这部分据我所知，似乎与获取加密块并通过套接字传输它们的底层 tcp 连接无关。为什么关闭的 tcp 连接会使之前约定的 ssl 方（客户端/服务器）的安全细节无效？这部分我不明白。请您详细说明一下吗？
@user384706 从技术角度来看，SSL/TLS 不关心连接，可以通过 UDP 使用（在 UDP 的情况下使用 TLS 的修改，命名为 DTLS）、命名管道、鸽子邮件等（我们曾经通过基于消息的通信渠道实现它）。但是，为了防止某些攻击，底层通道的断开也会自动使 SSL 连接无效。一般来说，如果您同时实现通信的客户端和服务器端并且您还控制 SSL 功能（例如，在使用我们的组件时），没有什么会强迫您这样做。
@Eugene：那么认为 TLS 会话无效是最佳实践吗？它不是任何 RFC 强制要求的，也不是 TLS RFC 所暗示的，对吧？
@user384706 个人我不知道当底层传输连接关闭时关闭 TLS 连接是强制性的，但基于此可能会有一些攻击。我认为这是一个单独深入调查的好话题。
@Eugene：我为此打开了stackoverflow.com/questions/4705715/…。关于这个线程，我是否应该假设我能做的最好的事情是在服务器中设置一个高保活超时？

【解决方案2】：

http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html#SSL：

SSL 会话是客户端和 Web 服务器之间用于安全通信的逻辑连接。在 SSL 会话建立期间，公钥密码学用于在客户端和服务器之间交换共享的秘密主密钥，并确定通信的其他特征，例如密码。使用 SSL 握手期间创建的共享密钥，使用对称密钥加密技术对会话中的后续数据传输进行加密和解密。

共享密钥的生成非常占用 CPU。为了避免为每个 TCP 连接生成共享密钥，可以为多个连接重用相同的 SSL 会话。客户端必须请求在随后的握手中重用相同的 SSL 会话，并且服务器必须缓存 SSL 会话标识符。当满足这些要求时，后续 TCP 连接的握手需要的服务器 CPU 会少得多（在某些测试中减少了 80%）。一般使用的所有 Web 浏览器都能够重用相同的 SSL 会话。但是，自定义 Web 客户端有时没有必要的支持。

【讨论】：