TCP 和 SSL/TLS 如何交互？答案

【问题标题】：How TCP and SSL/TLS interacts?TCP 和 SSL/TLS 如何交互？
【发布时间】：2018-02-05 15:21:53
【问题描述】：

SSL/TLS 在 TCP 层上运行。假设 TCP 连接在 SSL/TLS 会话关闭之前终止。 SSL/TLS 如何知道这一点？

【问题讨论】：

Stack Overflow 是一个编程和开发问题的网站。这个问题似乎离题了，因为它与编程或开发无关。请参阅帮助中心的What topics can I ask about here。也许Super User 或Unix & Linux Stack Exchange 会是一个更好的提问地点。

【解决方案1】：

TLS 会话大部分独立于底层 TCP 连接。

例如，您可以有多个 TCP 连接都使用同一个 TLS 会话，这些连接甚至可以并行共存。这实际上在实践中使用，例如用于 Web 浏览器。在某些 FTPS 实现中甚至要求控制和数据连接（不同的 TCP 连接）预计（重新）使用相同的 TLS 会话。请注意，会话不会简单地在另一个 TCP 连接中继续 - 仍然需要 TLS 握手来启动会话的“继续”，而只是一个简短的握手。

类似地，您可以在单个 TCP 连接中拥有多个 TLS 会话，但只能在彼此之后：启动一个 TLS 会话、关闭它、启动下一个等。虽然这不常用，但 TLS 会话实际上并不少见仅在传输一些纯数据（SMTP 中的STARTTLS，FTPS 中的AUTH TLS）或 TLS 关闭然后以纯数据传输更多数据（FTPS 中的CCC）后才开始。

SSL/TLS 如何知道这一点？

具体细节取决于 TLS 堆栈和此堆栈提供的 API。但通常如果底层 TCP 连接关闭，这会以某种方式向 TLS 堆栈发出信号。例如，对于 OpenSSL，SSL_read 将返回等于或小于 0 的值，您需要调用 SSL_get_error 以获取有关所发生情况的更多详细信息。同样，TCP 关闭不会隐式地使 TLS 会话无效。

【讨论】：

TLS 会话在 TLS 服务器正常运行期间定期失效，例如HTTPS。这可能会导致您在最后一段中描述的内容，而且很常见。
@EJP：我在最后一段中描述的是显式关闭现有 TCP 连接内的 TLS 连接，然后可能一段时间后在同一个 TCP 连接内进行另一个 TLS 握手。我认为这与服务器内缓存的 TLS 会话信息的失效没有任何关系。这些缓存的会话信息仅在会话恢复时需要，并且使这些信息无效不会导致现有的 TLS 会话关闭并创建一个新会话。
@EJP：可能是我们在谈论同名的不同事物：我的意思是 TLS 会话，因为它用于在 TCP 连接内传输数据。您可能指的是 TLS 会话结构（如 openssl SSL_SESSION），它用于存储有关会话的信息，该会话曾经存在过，可能当前存在或将来可能再次存在。
“TLS 会话”和“TLS 会话”没有区别，也没有“显式关闭 TLS 会话”之类的东西。只有失效，这阻止了进一步的恢复，这反过来意味着新的握手必须创建一个新的会话。

【解决方案2】：

SSL/TLS 在 TCP 层上运行。

正确。

假设 TCP 连接在 SSL/TLS 会话关闭之前终止。

然后 (a) TCP 连接已经结束，并且 (b) SSL/TLS 会话仍然存在。

SSL/TLS 如何知道这一点？

它不需要知道这一点。它只需要知道 TCP 连接的结束（由 TLS close_notify 消息发出信号），以及会话的结束（在会话失效时发生）。 TLS 会话的寿命可能比 TCP 连接长，反之亦然。

【讨论】：

TCP 连接的结束不是由close_notify 发出的信号。 close_notify 在 SSL 关闭时由对等方显式发送（例如，使用 OpenSSL SSL_shutdown）。这种 SSL 关闭（因此发送close_notify）不需要仅在 TCP 连接关闭时完成：例如，在 FTPS 中，在身份验证后关闭 SSL 并继续使用普通 TCP 控制连接并不少见。类似于关闭底层 TCP 连接不会神奇地从任何地方创建一个close_notify，close_notify 需要在 TCP 连接仍然打开时发送。

【解决方案3】：

SSL/TLS 使用心跳协议来检查连接是否仍然有效。因此，对于心跳请求，关闭的连接将响应否定。因此 SSL/TLS 将知道 TCP 连接已关闭。

【讨论】：

RFC 2246 或其后续版本中定义的 SSL 或 TLS 没有使用心跳协议。如果您不相信，请提供引用来支持您的主张。