本文是關於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年前已經標準化，並將在2023年6月與tlsv1.0一起在瀏覽器**商和內容交付網路中被棄用。
在poodle迫使它被業界和ietf棄用之前，sslv3已經進行了20年的部署。除非瀏覽器和庫中仍存在重大漏洞和支援，否則不應急於從您的內部網路中刪除tlsv1.2。
nist的800-52草案修訂版「要求所有**tls伺服器和客戶都支援配置了基於fips的密碼套件的tls1.2，並建議**機構制定遷移計畫以在2023年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採用=技術差距
最近，在2023年rsa大會和2023年戴爾技術世界大會上，針對tlsv1.3會議的受眾進行了有關計畫採用的調查。計畫用於內部網路的tlsv1.3部署很少。我認為這是乙個技術差距問題。
標準工作和行業已經提出了維護安全會話的工具，但仍然必須為通過中間盒技術被動地攔截流量的網路和安全管理功能提供路徑。
在採用階段之前，我們處於學習曲線。但是，這些工具已經準備就緒，實現已經在互操作性方面進行了充分測試，並且對於包括基於internet的會話在內的一些使用案例而言，安全優勢是明確的。（黑客週刊）
網路安全，加密技術
對稱加密技術 優點，效率高，缺點，私鑰不適合在網上傳輸，金鑰維護麻煩 非對稱加密技術 公鑰加密，私鑰解密 私鑰加密，公鑰解密 公私鑰來歷，作業系統根據給出的一串隨機數，通過某個函式運算產生乙個金鑰對，公鑰和私鑰，公鑰只能加密，私鑰負責解密 以私鑰解密為例，1我把私鑰儲存好，把公鑰給別人，別人就能給我...
網路安全幾種加密方式
下面介紹幾種網路傳輸加密方式 注.這些加密涉及明文傳輸的，需要在https協議上加密傳輸 1.金鑰雜湊 採用md5或者sha1等雜湊演算法，對明文進行加密 這裡的加密僅對人，不對機器，因為這些演算法機器可以用對應演算法算出來 2.對稱加密 優點 安全 可認證 適用場景 收發方數量固定，金鑰使用物件少...
網路安全 非對稱加密
公開金鑰密碼演算法也叫雙金鑰密碼演算法或非對稱金鑰密碼演算法，它的加密金鑰與解密金鑰不同。這種演算法需要形成乙個在數學上是相關聯的金鑰對 乙個公鑰和乙個私鑰 使用其中乙個金鑰加密資料，用另乙個金鑰來解密。公鑰可以公開傳遞，不需要安全通道，但與之對應的私鑰必須保密。在圖1中，發件人用收件人的公鑰加密了...