共用方式為

解決 TLS 1.0 問題，第 2 版

  • 發行項

本檔提供最新指引，說明在 Microsoft 作業系統上建置的軟體中快速識別和移除傳輸層安全性 （TLS） 通訊協定 1.0 版相依性，並遵循 Microsoft 提供的產品變更和新功能詳細數據，以保護您自己的客戶和 線上服務。 其用途是用來建置移轉至 TLS 1.2+ 網路環境的移轉計劃起點。 雖然這裡討論的解決方案可能會繼續並協助移除非 Microsoft 作業系統或密碼編譯連結庫中的 TLS 1.0 使用方式，但它們並非本文件的焦點。

TLS 1.0 是 1999 年首次定義的安全性通訊協定，用於透過電腦網路建立加密通道。 自 Windows XP/Server 2003 起，Microsoft 已支援此通訊協定。 雖然新式 OS 不再使用預設安全性通訊協定，但 TLS 1.0 仍支援回溯相容性。 不斷演進的法規需求以及 TLS 1.0 中的新安全性弱點，可讓公司完全停用 TLS 1.0。

Microsoft 建議客戶在環境中移除 TLS 1.0 相依性，並在可能的情況下在操作系統層級停用 TLS 1.0，以領先此問題。 假設軟體產業支援 TLS 1.0 的時間長度，強烈建議任何 TLS 1.0 淘汰方案包含下列專案：

  • 尋找/修正 TLS 1.0 或舊版安全性通訊協定硬式編碼實例的程式代碼分析。

  • 網路端點掃描和流量分析，以識別使用 TLS 1.0 或舊版通訊協定的作業系統。

  • 透過已停用 TLS 1.0 的整個應用程式堆疊進行完整回歸測試。

  • 將舊版操作系統和開發連結庫/架構移轉至預設可交涉 TLS 1.2 的版本。

  • 您企業用來識別任何 TLS 1.2 支援問題的作業系統之間的相容性測試。

  • 與您自己的商務夥伴和客戶協調，以通知他們移轉 TLS 1.0。

  • 瞭解停用 TLS 1.0 之後，哪些用戶端可能無法再連線到您的伺服器。

本文件的目標是提供可協助移除技術封鎖程式以停用 TLS 1.0 的建議，同時提高對您自己的客戶此變更影響的可見度。 完成這類調查有助於降低 TLS 1.0 中下一個安全性弱點的業務影響。 為了本檔的目的，對TLS 1.0 取代的參考也包含TLS 1.1。

企業軟體開發人員有策略性需求，需要採用更多未來安全且敏捷的解決方案（否則稱為 Crypto Agility），以處理未來的安全性通訊協定入侵。 雖然本檔提出消除 TLS 硬式編碼的敏捷式解決方案，但更廣泛的 Crypto Agility 解決方案已超出本檔的範圍。

Microsoft TLS 1.0 實作的目前狀態

Microsoft 的 TLS 1.0 實作 沒有已知的安全性弱點。 由於未來 通訊協定降級攻擊 和其他 TLS 1.0 弱點的可能性，因此建議盡可能移除與 TLS 1.2 以外的所有安全性通訊協定相依性（TLS 1.1/1.0/SSLv3/SSLv2）。

在規劃此移轉至 TLS 1.2+時，開發人員和系統管理員應該瞭解其員工和合作夥伴所開發應用程式中的通訊協定版本硬式編碼的可能性。 此處的硬式編碼表示 TLS 版本已修正為過期且較不安全的版本。 若未修改有問題的程式，就無法使用比硬式編碼版本還新的 TLS 版本。 如果沒有原始碼變更和軟體更新部署，就無法解決這類問題。 通訊協定版本硬式編碼在過去很常見，因為許多不同的瀏覽器和操作系統有不同的 TLS 支援層級。

Windows 中支援的 TLS 版本

許多操作系統的 TLS 版本預設值已過期，或需要考慮的支援上限。

圖 1：OS 版本的安全性通訊協議支援

Windows OS SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Windows Vista 啟用 啟用 啟用 不支援 不支援 不支援
Windows Server 2008 啟用 啟用 啟用 關閉* 關閉* 不支援
Windows 7 （WS2008 R2） 啟用 啟用 啟用 關閉* 關閉* 不支援
Windows 8 （WS2012） 停用 啟用 啟用 啟用 啟用 不支援
Windows 8.1 （WS2012 R2） 停用 啟用 啟用 啟用 啟用 不支援
Windows 10 停用 啟用 啟用 啟用 啟用 不支援
Windows 11 停用 啟用 啟用 啟用 啟用 啟用
Windows Server 2016 不支援 停用 啟用 啟用 啟用 不支援
Windows Server 2016 不支援 停用 啟用 啟用 啟用 不支援
Windows Server 2019 不支援 停用 啟用 啟用 啟用 不支援
Windows Server 2019 GS 版本 不支援 停用 停用 停用 啟用 不支援
Windows Server 2022 不支援 停用 停用 停用 啟用 啟用

Windows Server 2019 GS 版本符合 Microsoft SDL 規範，TLS 1.2 僅適用於一組受限的加密套件。

Windows Server 2022 版本符合 Microsoft SDL 規範、TLS 1.2 和 TLS 1.3，只有一組受限的加密套件。

您可以透過 這個選用的 Windows Update 套件，在 Windows Server 2008 上啟用 TLS 1.1/1.2。

如需 IE/Edge 中 TLS 1.0/1.1 淘汰的詳細資訊，請參閱 在 Microsoft Edge 和 Internet Explorer 11 中將 TLS 聯機現代化、 即將推出 Microsoft Edge 的網站兼容性影響變更，以及在新 Edge瀏覽器中停用 TLS/1.0 和 TLS/1.1

連線到您的 線上服務 時，判斷各種用戶端會要求哪些 TLS 版本，方法是參考 Qualys SSL Labs 的交握模擬。 此模擬涵蓋跨製造商的用戶端OS/瀏覽器組合。 如需詳細範例，請參閱 本文件結尾的附錄 A ，以取得連線至 www.microsoft.com 時，各種模擬用戶端 OS/瀏覽器組合交涉的 TLS 通訊協定版本。

如果尚未完成，強烈建議您企業、客戶和合作夥伴清查所使用的操作系統（後者兩個透過外展/通訊或至少 HTTP 使用者代理程式字串集合）。 此清查可進一步補充企業網路邊緣的流量分析。 在這種情況下，流量分析會讓連線至您服務的客戶/合作夥伴成功交涉 TLS 版本，但流量本身仍會保持加密狀態。

Microsoft 的工程改進功能可消除 TLS 1.0 相依性

自本檔的 v1 版本以來，Microsoft 已提供一些軟體更新和新功能，以支援 TLS 1.0 淘汰。 包括：

  • IIS 自訂記錄 ，以將用戶端 IP/使用者代理程式字串、服務 URI、TLS 通訊協定版本和加密套件相互關聯。

    • 透過這項記錄，系統管理員終於可以量化其客戶對弱式 TLS 的暴露程度。

  • SecureScore - 為了協助 Office 365 租使用者系統管理員識別自己的弱式 TLS 使用量，SecureScore 入口網站已建置為在 2018 年 10 月 Office 365 的 TLS 1.0 結束支援時共用此資訊。

    • 此入口網站為 Office 365 租用戶系統管理員提供他們向可能不知道自己 TLS 1.0 相依性的客戶伸出聯繫所需的重要資訊。

    • 如需詳細資訊，請造訪 https://securescore.microsoft.com/ 。

  • .Net Framework 更新以消除應用層級硬式編碼，並防止架構繼承的 TLS 1.0 相依性。

  • 開發人員指引和軟體更新已發行，可協助客戶識別和消除弱式 TLS 上的 .Net 相依性： 使用 .NET Framework 的傳輸層安全性 （TLS） 最佳做法

    • FYI：所有以 .NET 4.5 或以下為目標的應用程式都可能需要修改，才能支援 TLS 1.2。

  • TLS 1.2 已轉送至 Windows Server 2008 SP2 和 XP POSReady 2009 ，以協助客戶承擔舊版義務。

  • 將於 2019 年初發布更多公告，並在此文件的後續更新中傳達。

尋找並修正程序代碼中的 TLS 1.0 相依性

針對使用 Windows OS 提供的加密連結庫和安全性通訊協定的產品，下列步驟應該有助於識別應用程式中任何硬式編碼的 TLS 1.0 使用方式：

  1. 識別 AcquireCredentialsHandle（） 的所有實例。 這有助於檢閱者更接近TLS可能硬式編碼的程式代碼區塊。

  2. 檢閱硬式編碼 TLS 之 SecPkgContext_SupportedProtocols 和 SecPkgContext_連線 ionInfo 結構的任何實例。

  3. 在機器碼中，將 grbitEnabledProtocols 的任何非零指派設定為零。 這可讓操作系統使用其預設 TLS 版本。

  4. 如果啟用 FIPS 模式，是因為此文件中明確停用 TLS 1.0/1.1 所需的設定可能會發生衝突，請停用 FIPS 模式。 如需詳細資訊，請參閱 附錄 B 。

  5. 使用裝載於 Server 2012 或更新版本之 WinHTTP 來更新及重新編譯任何應用程式。

    1. 受控應用程式 – 針對最新的 .NET Framework 版本重建和複位目標

    2. 應用程式必須新增程序代碼，才能透過 WinHttpSetOption 支援 TLS 1.2

  6. 若要涵蓋所有基底，請掃描原始程式碼和在線服務組態檔，以取得以下對應至 TLS 硬式編碼中常用的列舉型別值：

    1. SecurityProtocolType

    2. SSLv2、SSLv23、SSLv3、TLS1、TLS 10、TLS11

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL或PROTOCOL_TLS

在上述所有情況下，建議的解決方案是移除硬式編碼通訊協定版本選取，並延遲操作系統預設值。 如果您使用 DevSkim， 請按下這裡 查看涵蓋上述檢查的規則，以搭配您自己的程式代碼使用。

Windows PowerShell 使用 .NET Framework 4.5，其不包含 TLS 1.2 做為可用的通訊協定。 若要解決此問題，有兩個解決方案可供使用：

  1. 變更有問題的文稿以包含下列專案：

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

  2. 將全系統登錄機碼（例如透過組策略）新增至任何需要從 .NET 應用程式建立 TLS 1.2 連線的電腦。 這會導致 .NET 使用將 TLS 1.2 新增為可用通訊協定的「系統預設」TLS 版本，而且當操作系統支援 TLS 版本時，它可讓腳本使用未來的 TLS 版本。 （例如 TLS 1.3）

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg：64

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg：32

解決方案（1）和（2）是互斥的，這意味著它們不需要一起實作。

使用最新的 .Net Framework 版本重建/複位目標受控應用程式

使用 4.7 之前的 .NET Framework 版本的應用程式可能會有限制，無論基礎 OS 預設值為何，有效限制 TLS 1.0 的支援。 如需詳細資訊，請參閱下圖和 .NET Framework 的傳輸層安全性 （TLS） 最佳做法。

重建受控應用程式

SystemDefaultTLSVersion 優先於 TLS 版本的應用層級目標。 建議的最佳做法是一律延遲 OS 預設 TLS 版本。 這也是唯一一個密碼編譯敏捷式解決方案，可讓您的應用程式利用未來的 TLS 1.3 支援。

如果您以舊版的 .NET Framework 為目標，例如 4.5.2 或 3.5，則應用程式預設會使用較舊且不建議使用的通訊協定，例如 SSL 3.0 或 TLS 1.0。 強烈建議您升級至較新版本的 .NET Framework，例如 .NET Framework 4.6，或為 'UseStrongCrypto' 設定適當的登錄機碼。

使用 TLS 1.2+ 進行測試

遵循上一節中建議的修正程式，產品應該經過回歸測試，以測試通訊協定交涉錯誤，並與企業中的其他操作系統相容。

  • 此回歸測試中最常見的問題是TLS交涉失敗，原因是來自不支援 TLS 1.2 的操作系統或瀏覽器的用戶端連線嘗試。

    • 例如，Vista 用戶端將無法與針對 TLS 1.2+ 設定的伺服器交涉 TLS，因為 Vista 支援的 TLS 版本上限為 1.0。 該客戶端應該在 TLS 1.2+ 環境中升級或解除委任。

  • 使用憑證型相互 TLS 驗證的產品可能需要額外的回歸測試，因為與 TLS 1.0 相關聯的憑證選擇程式代碼比 TLS 1.2 的效能低。

    • 如果產品會與來自非標準位置的憑證交涉 MTLS（在 Windows 中標準具名證書存儲之外），則該程式代碼可能需要更新以確保憑證已正確取得。

  • 服務相依性應該針對問題點進行檢閱。

    • 任何與 3個 rd 合作物件服務互通的服務，都應該對這些 3個 Rd 合作對象進行額外的 Interop 測試。

    • 任何使用中的非 Windows 應用程式或伺服器操作系統都需要調查/確認它們可支援 TLS 1.2。 掃描是判斷此專案最簡單的方式。

在在線服務中測試這些變更的簡單藍圖包含下列各項：

  1. 進行生產環境系統的掃描，以識別不支援 TLS 1.2 的作業系統。

  2. 掃描原始碼和在線服務組態檔中的硬式編碼 TLS，如「在程式代碼中尋找和修正 TLS 1.0 相依性」中所述

  3. 視需要更新/重新編譯應用程式：

    1. 受控應用程式

      1. 針對最新的 .NET Framework 版本重建。

      2. 確認 SSLProtocols 列舉的任何用法都設定為 SSLProtocols.None，才能使用 OS 預設設定。

    2. WinHTTP 應用程式 – 使用 WinHttpSetOption 重建以支援 TLS 1.2

  4. 在生產前或預備環境中開始測試，且所有安全性通訊協定都已透過登錄停用 TLS 1.2。

  5. 修正在測試中遇到任何 TLS 硬式編碼的剩餘實例。 重新部署軟體並執行新的回歸測試回合。

通知合作夥伴 TLS 1.0 淘汰方案

解決 TLS 硬式編碼並完成作業系統/開發架構更新之後，如果您選擇取代 TLS 1.0，就必須與客戶和合作夥伴協調：

  • 早期合作夥伴/客戶外展對於成功的 TLS 1.0 淘汰推出至關重要。 至少這應該包含部落格文章、白皮書或其他 Web 內容。

  • 合作夥伴都需要透過上述各節所述的操作系統/程式代碼掃描/回歸測試計劃來評估自己的TLS 1.2 整備程度。

推論

拿掉 TLS 1.0 相依性是驅動端對端的複雜問題。 Microsoft 和產業合作夥伴目前正對此採取動作，以確保我們的整個產品堆疊預設更安全，從我們的OS元件和開發架構，到建置在它們之上的應用程式/服務。 遵循本檔中的建議，可協助企業繪製正確的課程，並瞭解預期的挑戰。 這也將有助於您自己的客戶為轉換做好準備。

附錄 A：連線到 www.microsoft.com 的各種用戶端交握模擬，禮貌 SSLLabs.com

交握仿真的結果

附錄 B：在保留 FIPS 模式時取代 TLS 1.0/1.1

如果您的網路需要 FIPS 模式，但您也想要取代 TLS 1.0/1.1，請遵循下列步驟：

  1. 透過登錄設定 TLS 版本，將 [已啟用] 設定為零，以取代垃圾 TLS 版本。

  2. 透過組策略停用曲線 25519（僅限伺服器 2016）。

  3. 使用相關 FIPS 發行集不允許的演算法，停用任何加密套件。 對於 Server 2016（假設預設設定有效），這表示停用 RC4、PSK 和 NULL 加密。

參與者/感謝

Mark Cartwright
布萊恩·沙利文
派翠克叢林
邁克爾·斯科維塔
托尼·賴斯
David LeBlanc
莫蒂默·庫克
Daniel Sommerfeld
安德列·波波夫
米奇科短
賈斯汀·伯克
州長馬哈拉傑
布拉德·特納
肖恩·史蒂文森