通过SCTP流的TLS握手

Question

我正在通过TLS support over SCTP rfc，在那里我可以看到规范引用TLS握手必须在每个双向流上完成，然后才能启动通过传输的消息传输。

5.连接和双向流

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

因此，如果我有5个SCTP双向流打开，是否意味着我必须在5个双向流中分别进行密钥交换，证书验证等。

我在问这个问题，因为我觉得协议设计希望开发人员在每个流上重复TLS握手，即使套接字打开只是一个，并且对每个数据流执行相同的握手打开。

我也尝试在SCTP代码上编写一个示例TLS，其中TLS握手已通过流0完成，并且我能够通过所有5个流完成数据传输。

那么这是一些规范强制性的东西要做？如果我只通过一个流进行握手并通过所有相关流进行数据传输，会发生什么？有没有相关的安全漏洞？

有人请赐教我。

Answer 1

Meta：这不是一个真正的编程问题。它可能会更好地适用于安全性.SX涵盖SSL/TLS广泛和DTLS一些，虽然不是我记得的SCTP。

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

有两种可能的解决方案：

• 不要使用完整的握手。 TLS（以及之前的SSL）包括会话'恢复'，它使用双方已缓存的先前握手的结果（主要是协商的主密钥），通常具有一小时或一天的时间限制。这避免了通常昂贵的公钥密码学（密钥加密或协议和证书验证）以及可能的耗时的带外证书检查（未解耦的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工作，虽然两种协议级别都会增加排序开销，但效率不高。