本文是關於TLSv1.3採用的三部分系列的第三部分也是最後一部分。它解決了網絡加密和監控的選項，包括備用會話加密協議。
通過TLSv1.3的批准，並在IETF出版物隊列中，是時候考慮部署選項和障礙，並規劃此修訂內在的變化。
無論您計劃升級它，可能需要對內部應用程序和網絡體系結構進行重要規劃，而對於基於Internet的會話則需要更少的規劃。為即將發佈的版本提供支持庫和瀏覽器。
作為負責TLSv1.3的前IETF地區負責人，協助管理TLSv1.3監控和管理網絡的艱難對話並確保它們可能發生。有選項可以保持可見性，但為網絡確定和實施最合適的選擇需要仔細規劃。
在理想的世界中，組織可以在其內部網絡中無縫地將TLSv1.2的使用升級到TLSv1.3
對於一些企業來說，這種情況會發生，他們已經轉移到了沒有邊界或沒有單一可辨別的防火牆網關接入點的網絡。這些網絡已經依賴於安全的TLS會話-這是更難以攔截的-遵循RFC7525中TLSv1.2的部署最佳實踐。
在其他情況下，企業可能會放棄依靠帶外或被動TLS偵聽中間件，而是依靠端點上提供的信息和主動攔截來通過基於代理的解決方案進行監控。如果您的組織仍然依賴於TLSv1.0或TLSv1.1，那麼您應該最低限度地轉移到根據最佳實踐配置的TLSv1.2，因為棄用較舊的加密算法和密碼套件並提供前向保密。
其他的網絡體系結構會導致巨大的費用來檢修並且不能夠攔截加密的流量，但仍然希望在其內部網絡上應用會話加密的最佳實踐。
因此，IETF已經提出了迄今未成功的工作，以便在TLSv1.3中提供可見性。這些企業可能需要一個技術橋樑，使他們能夠在考慮轉向會話協議的情況下繼續監控其當前的方式，而會話攔截會更困難。到目前為止，這兩項提案都沒有推向採用。
提案包括TLS1.3中的數據中心使用靜態Diffie-Hellman和數據中心中可見性協商的TLS1.3選項。阻礙他們前進的兩個技術參數或障礙包括，工作組希望確保技術或擴展可能受數據中心或企業的約束，並且需要客戶選擇加入。問題在於，如果有方法攔截流量，那麼除了那些已經可以訪問服務器上的數據或TLS會話的終止點的人之外，還可以由未知或惡意的人員完成。
計劃繼續使用TLSv1.2
那些計劃繼續使用帶有RSA靜態密鑰的TLSv1.2進行被動攔截以管理和監控功能的公司有以下幾種選擇：
留在TLSv1.2中;棄用可能還有很長的路要走！
目前的法規不要求在內部網絡上進行會話加密，所以不太可能會看到這個特定的版本被認為是不允許在內部網絡上使用的。您組織的安全策略和體系結構可能會指導選擇適當的會話加密協議。
通過對象級加密或標記化來保護數據是必需的，並且將提供當前法規規定的保護。
在內部網絡上使用會話加密是最好的做法，目前TLSv1.2中沒有任何已知的漏洞可能會強制其棄用。
TLSv1.1在12年前已經標準化，並將在2018年6月與TLSv1.0一起在瀏覽器供應商和內容交付網絡中被棄用。
在POODLE迫使它被業界和IETF棄用之前，SSLv3已經進行了20年的部署。除非瀏覽器和庫中仍存在重大漏洞和支持，否則不應急於從您的內部網絡中刪除TLSv1.2。
NIST的800-52草案修訂版“要求所有政府TLS服務器和客戶都支持配置了基於FIPS的密碼套件的TLS1.2，並建議代理機構制定遷移計劃以在2020年1月1日之前支持TLS1.3。”該建議符合部署TLSv1.2的最佳實踐。NIST也棄用TLSv1.0，並建議不要在指南草案中使用TLSv1.1。
注意：請務必逐步淘汰任何對TLSv1.0和TLSv1.1的使用。對於IETF尚未棄用的這些協議的支持可能會在6月/7月的時間段內減少，因為CDN和其他組織將棄用他們對這些協議的支持。瀏覽器支持計劃尚不清楚，但來自AlexaTop100萬的Web流量統計數據顯示，TLSv1.0佔流量的0.8％，而TLSv1.1更低。
轉換您的網絡和安全體系結構以在端點上執行監視，以準備過渡到TLSv1.3
評估應用程序和系統的日誌和調試級別日誌。與供應商合作填補可視性方面的空白。
消除使用被動地觀察和解密流量的中間件。看看這些功能是否需要或者可以在網絡中的其他位置執行，最好是邊緣。通過代理（主動）進行監控仍然可以通過TLSv1.3進行，並且與TLSv1.2部署中的最終用戶類似。基於代理的監控是您終止TLS會話，執行監控，然後啟動新會話的地方。
尋找人工智能和機器學習解決方案來處理來自終端的日誌和警報
這裡有創新空間來更好地擴展安全和系統管理。未來和新興的協議選項可以更好地滿足您的內部網絡管理和監控要求，可以考慮採用更長期的解決方案。
以下三種可能性中的前兩種假定TLS在面向Internet的邊緣終止，而備用加密協議可以在服務器到服務器的配置中內部部署-第三種可以與TLS並行運行。
TCPcrypt
機會安全性應用於TCP會話，使頭部暴露。機會性安全意味著會話沒有被認證，這簡化了部署，因為它可以很容易地被自動化，但也使得它可以被攔截。
IPsec傳輸模式會將源地址和目標地址信息暴露給網絡管理人員。
組鍵控選項已經標準化：GDOI和MIKEY。
目前還鮮為人知，但許多實現允許調試會話提供完整，清晰的會話要收集在端點的文本進行故障排除。
為了使IPsec傳輸模式成為真正的競爭者，需要實現互操作性工作，但如果有需求，可能會發生此項工作。在IPsec的維護（IPsecMe）工作組是相當活躍。這需要客戶推動他們的供應商才能看到支持。或者，可以從端點使用IPsec隧道模式來保留數據包標頭中的源地址和目標地址信息。
IETF的網絡接口服務功能（I2NSF）工作組正在積極開展工作，以便通過數據中心甚至託管環境中的SDN控制器自動配置IPsec。
為數據中心使用而設計的多方協議
候選解決方案旨在與TLS並行運行。據我瞭解，患者的努力正在尋找解決方案，使所有監測點都可以看到客戶可以看到存在哪些監測點，同時保持前向保密。
有幾個候選解決方案，並且可能會在IETF中形成一個努力，在這個協議中專門為這個用例設計了一個協議。
如果感興趣，您可以跟隨並參與患者郵件列表，查看是否可以將工作轉化為安全的解決方案，以滿足企業和數據中心的需求。
TLSv1.3採用=技術差距
最近，在2018年RSA大會和2018年戴爾技術世界大會上，針對TLSv1.3會議的受眾進行了有關計劃採用的調查。計劃用於內部網絡的TLSv1.3部署很少。我認為這是一個技術差距問題。
標準工作和行業已經提出了維護安全會話的工具，但仍然必須為通過中間盒技術被動地攔截流量的網絡和安全管理功能提供路徑。
在採用階段之前，我們處於學習曲線。但是，這些工具已經準備就緒，實現已經在互操作性方面進行了充分測試，並且對於包括基於Internet的會話在內的一些使用案例而言，安全優勢是明確的。（黑客週刊）
閱讀更多 IT八卦陣 的文章
