我正在浏览TLS support over SCTP rfc，在那里我可以看到规范引用了在通过传输启动邮件传输之前必须对每个双向流进行TLS握手。
5。连接和双向流
TLS通过在其上建立连接来使用双向流。这意味着关联的连接数受到双向流数量的限制。 TLS握手协议分别用于每个双向流。
因此，如果我打开了5个SCTP双向流，是否意味着我必须分别对5个双向流中的每一个进行密钥交换，证书验证等？
我问这个是因为我发现协议设计要求开发人员在每个流上重复TLS握手是很奇怪的，即使打开的套接字只是一个，并且在打开的每个流上完成相同的握手
我还尝试在SCTP代码上编写示例TLS，其中TLS握手是在流0上完成的，我能够在所有5个流上进行数据传输。
这是一些规范强制要求吗？如果我只通过一个流进行握手并在所有相关流上进行数据传输会发生什么？是否存在相关的安全漏洞？
有人请赐教。
答案 0 :(得分：2)
Meta：这不是一个编程问题。它可能更适合安全性.SX覆盖SSL / TLS，DTLS一些，虽然不是我记得的SCTP。
TLS假设并要求TCP提供的服务，即（单个）顺序八位字节流，其中数据按顺序传送而不丢失或重复或重新排序，除非连接失败，在这种情况下数据传送完全停止且可检测到。记录格式和完整性检查算法（HMAC或AEAD）依赖于此。如果你通过流A发送TLS的'wire'格式的一部分而通过流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。还有一种变体协议，数据报 TLS rfc4347 matching TLS1.1或rfc6347 matching TLS1.2，它们自己进行碎片化（握手）只）和序列编号。这不需要比UDP提供更好的传输，即任何传送的数据报对应于已发送的数据报，但数据报可能丢失，重复或错误。因此，它可以在SCTP上工作，尽管两种协议级别都会增加测序开销的效率低下。