通过 SCTP 流的 TLS 握手
TLS handshake over SCTP streams
我正在浏览 TLS support over SCTP rfc，在那里我可以看到规范引用了 TLS 握手必须在每个双向流上完成，然后才能通过传输启动消息传输。
5. Connections and Bi‐directional Streams
TLS makes use of a bi‐directional stream by establishing a connection over it. This means that the number of connections for an association is limited by the number of bi‐directional streams. The TLS handshake protocol is used on each bi‐directional stream separately.
所以如果我打开了 5 个 SCTP 双向流，是否意味着我必须对 5 个双向流中的每一个分别进行密钥交换、证书验证等？
我问这个是因为我觉得很奇怪协议设计希望开发人员在每个流上重复 TLS 握手，即使打开的套接字只有一个，并且对每个流进行相同的握手流已打开。
我还尝试通过 SCTP 代码编写示例 TLS，其中 TLS 握手是在流 0 上完成的，我能够在所有 5 个流上进行数据传输。
那么这是不是有一些规范强制性的事情要做？如果我只对一个流进行握手并对所有相关流进行数据传输，会发生什么情况？是否存在任何相关的安全漏洞？
请哪位大神赐教
Meta: 这不是真正的编程问题。它可能更适合 security.SX 广泛涵盖 SSL/TLS 和 DTLS 一些，虽然不是我记得的 SCTP。
TLS 假定并需要 TCP 提供的服务，即（单个）顺序八位字节流，其中数据按顺序传送，不会丢失、重复或重新排序，除非连接失败，在这种情况下数据传送完全停止并且可以检测到。记录格式和完整性检查算法（HMAC 或 AEAD）依赖于此。如果您通过流 A 发送 TLS 的 'wire' 格式的一部分，而另一部分通过流 B 发送，并且 B 上的部分先于 A 上的部分到达，或者 A 已交付但 B 丢失，反之亦然，TLS 将丢失大时代。
有两种可能的解决方案：
不要使用完全握手。 TLS（和之前的 SSL）包括会话 'resumption' 它使用双方缓存的先前握手的结果（主要是协商的主密钥），通常有一些时间限制，例如一小时或一天。这避免了通常昂贵的 public-key 加密（密钥加密或协议和证书验证）以及可能耗时的带外证书检查（unstapled OCSP 或 CRL 或替代方案）。它使用仅 1.5 次交换的 'abbreviated' 握手：ClientHello、ServerHello 加上 CCS 和 Finished、CCS 和 Finished，除了 possibly ClientHello.
rfc3436 第 8.2 8.3 8.4 节中的示例使用（并隐式推荐）这个。
有一种可选的会话恢复替代形式，使用不多，它减少了多对一（或多对少）情况下服务器的负载，而不是服务器实际缓存它的有关会话的信息，它提供客户端发回的客户端 an encrypted/sealed 'ticket'。
使用 DTLS。 还有一个变体协议，Datagram TLS rfc4347 matching TLS1.1 or rfc6347 matching TLS1.2自己的碎片（仅握手）和序列编号。这不需要比 UDP 提供的传输更好的传输方式，即任何传送的数据报都对应于已发送的数据报，但数据报可能会丢失、重复或顺序错误。因此，它将在 SCTP 上工作，尽管在两个协议级别都增加排序开销时效率低下。
我正在浏览 TLS support over SCTP rfc，在那里我可以看到规范引用了 TLS 握手必须在每个双向流上完成，然后才能通过传输启动消息传输。
5. Connections and Bi‐directional Streams
TLS makes use of a bi‐directional stream by establishing a connection over it. This means that the number of connections for an association is limited by the number of bi‐directional streams. The TLS handshake protocol is used on each bi‐directional stream separately.
所以如果我打开了 5 个 SCTP 双向流，是否意味着我必须对 5 个双向流中的每一个分别进行密钥交换、证书验证等？
我问这个是因为我觉得很奇怪协议设计希望开发人员在每个流上重复 TLS 握手，即使打开的套接字只有一个，并且对每个流进行相同的握手流已打开。
我还尝试通过 SCTP 代码编写示例 TLS，其中 TLS 握手是在流 0 上完成的，我能够在所有 5 个流上进行数据传输。
那么这是不是有一些规范强制性的事情要做？如果我只对一个流进行握手并对所有相关流进行数据传输，会发生什么情况？是否存在任何相关的安全漏洞？
请哪位大神赐教
Meta: 这不是真正的编程问题。它可能更适合 security.SX 广泛涵盖 SSL/TLS 和 DTLS 一些，虽然不是我记得的 SCTP。
TLS 假定并需要 TCP 提供的服务，即（单个）顺序八位字节流，其中数据按顺序传送，不会丢失、重复或重新排序，除非连接失败，在这种情况下数据传送完全停止并且可以检测到。记录格式和完整性检查算法（HMAC 或 AEAD）依赖于此。如果您通过流 A 发送 TLS 的 'wire' 格式的一部分，而另一部分通过流 B 发送，并且 B 上的部分先于 A 上的部分到达，或者 A 已交付但 B 丢失，反之亦然，TLS 将丢失大时代。
有两种可能的解决方案：
不要使用完全握手。 TLS（和之前的 SSL）包括会话 'resumption' 它使用双方缓存的先前握手的结果（主要是协商的主密钥），通常有一些时间限制，例如一小时或一天。这避免了通常昂贵的 public-key 加密（密钥加密或协议和证书验证）以及可能耗时的带外证书检查（unstapled OCSP 或 CRL 或替代方案）。它使用仅 1.5 次交换的 'abbreviated' 握手：ClientHello、ServerHello 加上 CCS 和 Finished、CCS 和 Finished，除了 possibly ClientHello.
rfc3436 第 8.2 8.3 8.4 节中的示例使用（并隐式推荐）这个。
有一种可选的会话恢复替代形式，使用不多，它减少了多对一（或多对少）情况下服务器的负载，而不是服务器实际缓存它的有关会话的信息，它提供客户端发回的客户端 an encrypted/sealed 'ticket'。
使用 DTLS。 还有一个变体协议，Datagram TLS rfc4347 matching TLS1.1 or rfc6347 matching TLS1.2自己的碎片（仅握手）和序列编号。这不需要比 UDP 提供的传输更好的传输方式，即任何传送的数据报都对应于已发送的数据报，但数据报可能会丢失、重复或顺序错误。因此，它将在 SCTP 上工作，尽管在两个协议级别都增加排序开销时效率低下。