通過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工作，雖然兩種協議級別都會增加排序開銷，但效率不高。