年初，在一份關於2018-2019年網路問題和可及性的報告中 TLS 1.3 的傳播是不可避免的。 前段時間，我們自己部署了傳輸層安全協定1.3版本，在收集和分析資料之後，我們終於準備好談論這個過渡的特性。
IETF TLS 工作小組主席 :
“簡而言之，TLS 1.3 應該為未來 20 年更安全、更有效率的互聯網奠定基礎。”
設計 花了10年的時間。 我們 Qrator Labs 以及業界其他公司從最初的草案開始就密切關注協議創建過程。 在此期間，需要連續編寫28個版本的草案，才能最終在2019年看到一個平衡且易於部署的協議。 市場對 TLS 1.3 的積極支持已經顯而易見：實施經過驗證且可靠的安全協議滿足了時代的需求。
Eric Rescorla（Firefox 技術長兼 TLS 1.3 的唯一作者）表示 :
「這是 TLS 1.2 的完全替代，使用相同的金鑰和證書，因此客戶端和伺服器如果都支援 TLS 1.3，就可以自動透過 TLS 1.3 進行通信，」他說。 “庫級別已經有了很好的支持，Chrome 和 Firefox 默認啟用 TLS XNUMX。”
同時，IETF 工作小組中的 TLS 也即將結束 ，聲明舊版的 TLS（僅不包括 TLS 1.2）已過時且無法使用。 最終的 RFC 最有可能在夏末之前發布。 這是另一個向IT產業發出的訊號：加密協定的更新刻不容緩。
Github 上提供了當前 TLS 1.3 實現的列表，供任何尋找最合適庫的人使用： 。 顯然，對更新協議的採用和支持將會而且已經在迅速進展。 對現代世界中基本加密的理解已經廣泛傳播。
自 TLS 1.2 以來發生了哪些變化？
的 :
「TLS 1.3 如何讓世界變得更美好？
TLS 1.3 包含某些技術優勢（例如建立安全連線的簡化握手過程），並且還允許用戶端更快地恢復與伺服器的會話。 這些措施旨在減少弱連結上的連線設定延遲和連線失敗，這通常被用作僅提供未加密的 HTTP 連線的理由。
同樣重要的是，它取消了對幾種遺留且不安全的加密和哈希演算法的支持，這些演算法仍然允許（儘管不建議）與早期版本的TLS 一起使用，包括SHA-1、MD5、DES、 3DES 和AES-CBC。新增對新密碼套件的支援。 其他改進包括對握手的更多加密元素（例如，證書資訊的交換現在已加密），以減少潛在流量竊聽者的線索數量，以及在使用某些密鑰交換模式時改進前向保密性，以便通信即使用於加密的演算法將來受到損害，也必須始終保持安全。”
現代協議和 DDoS 的開發
正如您可能已經讀到的，在協議的開發過程中 ，在 IETF TLS 工作小組中 。 現在很明顯，各個企業（包括金融機構）必須改變他們保護自己網路的方式，以適應協議現在內建的 .
文件中列出了可能需要這樣做的原因， 。 這份長達 20 頁的論文提到了幾個範例，其中企業可能希望解密帶外流量（PFS 不允許），以實現監控、合規性或應用層 (L7) DDoS 保護目的。
雖然我們當然不准備猜測監管要求，但我們的專有應用程式 DDoS 緩解產品（包括解決方案 敏感和/或機密資訊）是在 2012 年創建時考慮到 PFS 的，因此我們的客戶和合作夥伴在伺服器端更新 TLS 版本後無需對其基礎設施進行任何更改。
此外，自實施以來，尚未發現傳輸加密相關的問題。 官方消息：TLS 1.3 已準備好投入生產。
然而，下一代協議的開發仍然存在一個問題。 問題在於，IETF 中的協議進展通常嚴重依賴學術研究，而緩解分散式阻斷服務攻擊領域的學術研究狀況卻很慘淡。
所以，一個很好的例子是 IETF 草案“QUIC 可管理性”是即將推出的 QUIC 協議套件的一部分，其中指出“檢測和緩解 [DDoS 攻擊] 的現代方法通常涉及使用網絡流數據的被動測量。”
事實上，後者在真實的企業環境中非常罕見（並且僅部分適用於ISP），並且無論如何都不太可能成為現實世界中的“一般情況” - 但經常出現在科學出版物中，通常不受支援通過測試所有潛在的 DDoS 攻擊，包括應用程式級攻擊。 後者，至少由於 TLS 的全球部署，顯然無法透過網路資料包和流量的被動測量來檢測。
同樣，我們還不知道 DDoS 緩解硬體供應商將如何適應 TLS 1.3 的現實。 由於支援帶外協議的技術複雜性，升級可能需要一些時間。
設定正確的目標來指導研究是 DDoS 緩解服務提供者面臨的主要挑戰。 可以開始開發的一個領域是 在 IRTF，研究人員可以與業界合作，完善自己對具有挑戰性的產業的知識，並探索新的研究途徑。 我們也熱烈歡迎所有研究人員，如果有任何問題或建議，可以透過以下地址與我們聯繫：
來源： www.habr.com