我正在查看TLS support over SCTP rfc，在那里我可以看到规范引用必须在通过传输启动消息传输之前对每个双向流进行 TLS 握手。
5。连接和双向流
TLS 通过在其上建立连接来使用双向流。这意味着关联的连接数受双向流数的限制。 TLS 握手协议分别用于每个双向流。
如果我打开了 5 个 SCTP 双向流，是否意味着我必须对 5 个双向流中的每一个分别进行密钥交换、证书验证等？
我问这个是因为我觉得很奇怪，协议设计希望开发人员在每个流上重复 TLS 握手，即使打开的套接字只是一个，并且在每个打开的流上都进行相同的握手.
我还尝试编写一个示例 TLS over SCTP 代码，其中 TLS 握手是在流 0 上完成的，我能够在所有 5 个流上进行数据传输。
那么，是否需要做一些规范强制性的事情？如果我只对一个流进行握手并在所有相关流上进行数据传输会发生什么？是否存在相关的安全漏洞？
有人请赐教。
【问题讨论】：
标签： sockets ssl openssl rhel7 sctp
Meta：这并不是真正的编程问题。它可能更适合 security.SX 广泛涵盖 SSL/TLS 和 DTLS，虽然不是我记得的 SCTP。
TLS 假定并要求 TCP 提供的服务，即（单个）顺序八位字节流，其中数据按顺序传递，不会丢失、重复或重新排序，除非连接失败，在这种情况下数据传递完全停止且可检测.记录格式和完整性检查算法（HMAC 或 AEAD）依赖于此。如果您通过流 A 发送 TLS 的“有线”格式的一部分，通过流 B 发送另一部分，并且 B 上的部分在 A 上的之前到达，或者 A 已交付但 B 丢失，反之亦然，则 TLS 将丢失大量时间。
有两种可能的解决方案：
不要使用 FULL 握手。 TLS（和之前的 SSL）包括会话 'resumption'，它使用前一个结果（主要是协商的主密钥）双方缓存的握手，通常有一个小时或一天的时间限制。这避免了通常昂贵的公钥加密（密钥加密或协议和证书验证）以及可能耗时的带外证书检查（未装订的 OCSP 或 CRL 或替代方案）。它使用只有 1.5 次交换的“缩写”握手：ClientHello、ServerHello 加上 CCS 和 Finished、CCS 和 Finished，除了 可能 ClientHello 之外，所有这些都很短。
rfc3436 的 8.2 8.3 8.4 节中的示例使用（并暗示推荐）这个。
有一种可选的会话恢复形式，使用不多，它减少了多对一（或多对少）情况下服务器的负载，而不是服务器实际缓存其关于一个会话，它提供客户端发回的客户端an encrypted/sealed 'ticket'。
使用 DTLS。 还有一个变体协议，Datagram TLS rfc4347 matching TLS1.1 或 rfc6347 matching TLS1.2，它自己进行分段（仅握手）和序列编号。这并不需要比 UDP 提供更好的传输，即任何交付的数据报都对应于已发送的数据报，但数据报可能会丢失、重复或排序错误。因此，它将在 SCTP 上运行，尽管在两个协议级别都增加了排序开销时效率低下。
【讨论】：