Sockets SCTP流上的TLS握手

我正在浏览，在那里我可以看到规范引用，在通过传输启动消息传输之前，必须在每个双向流上进行TLS握手

5.连接和双向流 TLS通过在双向流上建立连接来利用双向流。这意味着关联的连接数量受到双向流数量的限制。TLS握手协议分别用于每个双向流

因此，如果我打开了5个SCTP双向流，这是否意味着我必须对5个双向流中的每一个单独进行密钥交换、证书验证等

我这样问是因为我觉得很奇怪，协议设计希望开发人员在每个流上重复TLS握手，即使打开的套接字只有一个，并且在每个打开的流上都进行相同的握手

我还尝试编写了一个示例TLS over SCTP代码，其中TLS握手是在流0上完成的，我能够在所有5个流上进行数据传输

那么这是一些必须要做的事情吗？如果我只在一个流上进行握手，而在所有相关流上进行数据传输，会发生什么？是否存在任何相关的安全漏洞

---

有人请告诉我这一点。

Meta:这不是一个真正的编程问题。它可能更适合security.SX，它涵盖了广泛的SSL/TLS，还有一些DTL，尽管我记得不是SCTP

TLS假定并需要TCP提供的服务，即（单个）顺序八位字节流，其中数据按顺序传输，不会丢失、重复或重新排序，除非连接失败，在这种情况下，数据传输完全停止且可检测。记录格式和完整性检查算法（HMAC或AEAD）依赖于此。如果您通过流A发送TLS的“wire”格式的一部分，通过流B发送另一部分，并且B上的部分在A上的部分到达之前到达，或者A已交付但B丢失，或者反之亦然，TLS将丢失bigtime

有两种可能的解决方案：

• 不要使用完全握手。TLS（以及之前的SSL）包括会话“恢复”，它使用双方缓存的前一次握手的结果（主要是协商的主秘密），通常有一个小时或一天的时间限制。这避免了通常代价高昂的公钥加密（密钥加密或协议和证书验证）以及可能耗时的带外证书检查（未部署的OCSP或CRL或替代方案）。它只使用了1.5次交换的“缩写”握手：ClientHello、ServerHello加上CCS和Finished、CCS和Finished，除了可能的ClientHello之外，所有这些都是简短的
  rfc3436第8.2.8.3.8.4节中的示例使用（并暗示建议）这一点
  有一种可选的会话恢复替代形式，使用不多，它可以在多对一（或多对少）的情况下减少服务器上的负载，在这种情况下，服务器不是实际缓存关于会话的信息，而是提供客户端发回的客户端

• 使用DTL。还有一种变体协议，即数据报TLS或，它自己进行分段（仅限握手）和序列编号。这并不需要比UDP提供更好的传输，即任何交付的数据报都对应于已发送的数据报，但数据报可能丢失、复制或排序错误。因此，它将在SCTP上工作，尽管这两个协议级别都会增加排序的开销，这是低效的

---

谢谢你，戴夫。只需在此基础上进行一次查询。假设@pointA打开的SCTP流是，out:5，in:5，@pointB是，out:5，in:5。所以我知道我们将进行5次TLS握手。但是，对于TLS握手和数据传输，我选择@pointA和@pointB的SCTP流是否存在相同的约束（在发送响应时）？我得到了来自同一侧的数据块的TLS HMAC-SCTP流依赖关系，但是我们对消息的响应数据有任何约束吗？我可以从流2上的pointA发送TLS数据并在流4上接收响应吗？