代码之家 › 专栏 › 技术社区 › neo

SCTP流上的TLS握手

sctp rhel7 openssl ssl sockets

3

neo · 技术社区 · 8 年前

我正在通过 TLS support over SCTP rfc ,其中我可以看到规范引用了TLS握手必须在通过传输发起消息传输之前在每个双向流上完成。

5.连接和双向流

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

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

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

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

那么,这是一些规范强制要求的事情吗?如果我只在一个流上进行握手,而在所有相关流上进行数据传输,会发生什么?是否存在相关的安全漏洞?

有人请告诉我这一点。

1 回复 | 直到 4 年前

1

3

Community CDub 3 年前

元: 这实际上不是一个编程问题。它可能更适合安全性。SX广泛涵盖SSL/TLS,还有一些DTL,尽管我记得不是SCTP。

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

有两种可能的解决方案:

不要完全握手。 TLS(以及之前的SSL)包括会话 “恢复” 它使用双方缓存的前一次握手的结果(主要是协商的主秘密),通常有一个小时或一天的时间限制。这避免了通常代价高昂的公钥加密(密钥加密或协议和证书验证)以及可能耗时的带外证书检查(未标记的OCSP或CRL或替代方案)。它使用 “缩写” 只有1.5次交换的握手:ClientHello、ServerHello加上CCS和Finished、CCS和Finished,所有这些都很短,除了 可能地 克利恩塞洛。

rfc3436第8.2节、第8.3节和第8.4节中的示例使用(并暗示建议)了这一点。

有一种可选的会话恢复替代形式,使用不多,它在多对一(或多对少)的情况下减少了服务器的负载,在这种情况下,服务器不是实际缓存其关于会话的信息,而是向客户端提供 an encrypted/sealed 'ticket' 客户端发送回的。
使用DTL。 还存在变体协议, 数据报 TLS rfc4347 matching TLS1.1 或 rfc6347 matching TLS1.2 其执行其自身的分段(仅握手)和序列编号。这并不需要比UDP更好的传输,也就是说,任何传递的数据报都对应于发送的数据报,但数据报可能丢失、重复或排序错误。因此,它将在SCTP上工作,尽管这两个协议级别都增加了测序的开销,但效率低下。