Defaults.Exposed › 修復 › 現代加密（TLS 版本與密碼套件）

如何修復 現代加密（TLS 版本與密碼套件）

TLS 是那把鎖，它打亂在你訪客和你網站之間流動的資料。有兩件事讓這把鎖可信：使用現代版本的 TLS（不是那些老舊、已被攻破的版本），以及使用強壯的密碼套件（實際的打亂配方）。本頁兩者都講——外加幾個不影響你評分、卻值得了解的相關設定。

對您業務的關鍵影響： 如果你的網站跑在過時的加密或孱弱的密碼套件上，你客戶輸入的隱私資訊——登入、卡號、聯絡方式——可能在共享網路上被悄悄攔截讀取，而且你會通不過銀行、支付處理商和大客戶如今在合作前要求的那些安全檢查。

這會讓您付出什麼代價

• 一個客戶在飯店或咖啡廳 Wi-Fi 上付款或登入，一個過時的連線或弱密碼套件讓那個網路上的陌生人讀到了他的卡號和密碼，而欺詐——以及那通憤怒的電話——直接追溯回你的網站。
• 你申請收取卡片支付（或你的支付服務商重新稽核你），卻因過時的 TLS 或一個被禁的密碼套件違反支付安全規則而被拒——你的線上結帳被凍結，直到修好。
• 一個大客戶的 IT 團隊在簽約前做例行安全掃描，看到你的網站仍允許已被攻破的加密，把你標為風險——合約就卡在一個零成本就能修好的問題上。
• 一樁資料保護投訴或外洩落到你桌上，監管方問的第一個問題是你是否「恰當地」保護了客戶資料——而跑著一個多年來公開已知被攻破的加密，是個非常難給的答案。
• 你的網站顯示一把鎖，於是所有人都以為它完全安全，這個缺口多年無人察覺——直到一次被攔截的登入或卡號變成一樁遠比那個免費修復更昂貴的事故。

為什麼它重要。 安全的加密是隱形的；過時或孱弱的加密是一個隱患，安靜地待著，直到它害你失去一個客戶、一份合約或一次合規通過的那天。TLS 版本和密碼套件檢查是真正撬動你評分的那兩部分，而兩者通常都是一個免費設定——把老舊、已被攻破的選項繼續開著，沒有任何好處。

大白話版

當有人訪問你的網站時，他輸入的一切——登入、卡號、姓名、電話、訊息——都在傳輸途中被打亂，讓陌生人讀不到。做這個打亂工作的技術叫 TLS（你也可能聽到它的舊名 SSL）。要讓這個打亂真正安全，兩件事必須對：

1. TLS 版本——你用的是哪一代技術。早期版本（TLS 1.0 和 1.1）多年來已被公開攻破；安全的是 TLS 1.2 和 TLS 1.3。
2. 密碼套件——TLS 用來做打亂的具體配方。有些密碼套件（比如 RC4、DES 和 3DES）已被破解、如今被禁；現代密碼套件仍然強壯。

本頁兩者都講，因為一個網站可能一個做對、另一個做錯。你可以有一把現代鎖卻仍開著一個舊的、可破解的配方——或者一個強配方被一把過時的鎖保護著。任一缺口都是一扇敞開的門。兩者通常都由對你伺服器或主機設定的同一個免費改動關上。

這會讓你付出什麼代價

• 一個客戶在公共 Wi-Fi 上被劫。 某人從飯店、咖啡廳或機場登入帳戶或付款。因為你的網站仍允許一個舊 TLS 版本或一個弱密碼套件，同一網路上的陌生人把連線逼降到那個可破解的選項，即時讀到了他的密碼和卡號。欺詐落在客戶身上，但罵名——和那通客服電話——落在你身上。
• 你的卡片支付被關掉。 支付安全規則（PCI DSS）要求 TLS 1.2 為最低標準，並明確禁止 RC4 這樣的弱密碼套件。當你的處理商重新稽核你、或當你申請收卡時，一個過時的設定通不過檢查，你的結帳被凍結，直到修好——恰好在現金流最不該出問題的時刻。
• 一筆生意卡在安全審查裡。 在一個大客戶簽約前，他們的 IT 團隊做一次例行掃描。它立刻標記出你的網站仍接受已被攻破的加密——這類發現看起來馬虎，讓買家懷疑還有什麼是鬆的。合約就為一個零成本就能修好的問題懸在半空。
• 監管方問出那個尷尬的問題。 任何投訴或外洩之後，資料保護機構最先想知道的，就是你是否「恰當地」保護了個人資料。跑著一個多年來公開已知被攻破的加密非常難辯護，而「我們沒意識到舊版本還開著」不是一個讓人舒服的答案。
• 它在那把鎖後面藏了好幾年。 因為你的網站仍顯示一把正常的鎖，沒人察覺那個缺口——直到一次被攔截的登入或卡號變成一樁遠比那個五分鐘修復更昂貴的公開事故。

它到底是什麼

TLS 版本

一個網站並不只支援一個 TLS 版本——它能同時提供好幾個，讓每個訪客的瀏覽器各自挑選。一個現代訪客會用可用的最新版本，看到一把正常的鎖。危險在於老舊、已被攻破的版本可以作為一扇敞開的後門，待在好版本旁邊：攻擊者能把訪客的連線「降級」到 TLS 1.0 或 1.1，再利用那些版本裡已知的弱點（BEAST 和 POODLE 攻擊是著名的例子）來解密流量。

所以我們的檢查連上你的網站，逐一測試每個版本——TLS 1.0、1.1、1.2 和 1.3——看你的伺服器仍接受哪些。下面是「好」長什麼樣、以及它如何評分：

• TLS 1.3（帶或不帶 1.2），且沒有遺留版本： 最佳結果——一個現代、乾淨的設定。滿分。
• 只有 TLS 1.2，沒有 1.3： 安全且通過，但你把最新、最快的版本擱在了一邊。多數分；啟用 1.3 值得做。
• TLS 1.0 或 1.1 仍被接受： 自動失敗，記零分並標為關鍵——1.2/1.3 也能用並不重要，因為被攻破的版本才是那扇敞開的門。這是你必須修的。

密碼套件

版本一旦選定，TLS 就挑一個密碼套件——實際打亂資料的演算法。多數現代密碼套件都強壯。少數已被攻破、絕不能用：RC4（它的打亂有偏、會洩露明文）、DES（金鑰太短、可被暴力破解）、3DES（易受「Sweet32」攻擊），外加 NULL（根本不加密）、EXPORT 級密碼套件（被刻意削弱——FREAK 和 Logjam 攻擊）、以及匿名密碼套件（不做身份核查，於是冒牌貨能坐到中間）。

我們的密碼套件檢查做兩件事。首先它看你的伺服器實際與我們協商出的密碼套件。然後——這是重要的部分——它主動嘗試用幾個已知被攻破的密碼套件握手（RC4、3DES、EXPORT、NULL 和匿名變體）。一台伺服器在和現代用戶端對話時可能挑一個強密碼套件，卻仍在攻擊者堅持時接受一個弱的——而那是一個真實的降級風險。如果你的伺服器接受任何被禁的密碼套件，檢查就標記它；接受一個關鍵的（比如 RC4 或 NULL）則是失敗。（在 TLS 1.3 上這裡沒什麼可擔心的——那個版本從設計上移除了每一個弱密碼套件，所以探測被略過。）

三個參考性的附加項

有三個相關項目被回報但不影響你的評分——它們被標為參考性，因為它們無法從外部可靠驗證，而在任何現代伺服器或 CDN 上它們已被正確處理：

• TLS 壓縮（CRIME 攻擊）： 一個舊特性，若開著，可能讓攻擊者套出工作階段 Cookie。它在每個現代 Web 伺服器裡預設停用已超過十年，所以今天實質上是個非問題。
• OCSP stapling： 一個效能與隱私上的小妙處，你的伺服器預先取來「它的憑證未被撤銷」的證明，於是每個訪客不必自己去問憑證授權機構（那更慢、還洩露瀏覽資料）。像 Cloudflare 的 CDN 自動做這個。
• 安全重協商： 一個舊缺陷（CVE-2009-3555）的修復，那個缺陷曾讓攻擊者往工作階段裡注入資料。TLS 1.3 完全移除了重協商，所以在那裡是個非問題，而現代 TLS 1.2 伺服器預設實作該修復。

我們呈現這些，是為了讓你的 IT 人員掌握全貌，但對絕大多數業主而言沒什麼要做的——你的分數由上面的版本和密碼套件檢查驅動。

如何修復（免費，約 30 分鐘）

把這個交給你的 IT 人員——修復免費。 這一節是給管理你網域、網站或主機的人看的。修復是一個設定改動，不是一筆採購；我們只對長期監控你的加密是否保持正確設定收費。下面這個單一的現代設定一次修好版本和密碼套件兩項發現。

最簡單可靠的辦法是產生一份已知良好的設定，而不是手寫一份：把你的伺服器類型貼進 Mozilla 的 SSL 設定產生器（https://ssl-config.mozilla.org/），選 **「Intermediate」**設定檔（廣泛相容）或 「Modern」（僅 TLS 1.3，若你不需要支援任何老舊東西）。它會為你輸出正確的 ssl_protocols 和 ssl_ciphers 行。

按平台分：

1. Cloudflare 或託管主機——通常一兩下點選。 在 Cloudflare 裡：SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2，那裡的密碼套件由它替你管理（平台不會提供被禁的密碼套件）。多數託管主機和建站工具（Squarespace、Wix、Shopify、現代 WordPress 主機）已強制 TLS 1.2+ 加強密碼套件——只要確認沒有任何「legacy TLS」或「老瀏覽器相容」選項還開著。
2. Nginx。 設定僅限現代的版本和一份明確的強密碼套件清單，然後重載：

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

   （TLS 1.3 需要機器上有 OpenSSL 1.1.1+。）
3. Apache。 停用舊版本並釘一份強密碼套件清單，然後重啟：

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS。 用免費的 IIS Crypto 工具（或等效的登錄設定）停用 TLS 1.0 和 1.1、停用 RC4/DES/3DES/NULL/EXPORT 密碼套件，並保留 TLS 1.2 和 1.3 及強密碼套件啟用。該工具的「Best Practices」範本一鍵完成所有這些。
5. 參考性附加項（可選，免費）。 如果你想來個乾淨徹底：在 Nginx 上加 ssl_stapling on; ssl_stapling_verify on;（帶一行 resolver）做 OCSP stapling；在 Apache 上加 SSLUseStapling On。TLS 壓縮和安全重協商在現代伺服器上已預設安全——無需動作。在 Cloudflare 上這三項都自動處理。
6. 驗證，然後回這裡重新檢測。 確認只剩安全的版本和密碼套件——例如用 nmap --script ssl-enum-ciphers -p 443 yourdomain.com，或在 https://ssl-config.mozilla.org/ 連結的工具裡測試——然後重新執行本項檢查。在可能的地方，把 TLS 1.3 與 1.2 一起啟用：它既更快也更安全。

常見錯誤

• 「我們有一把鎖，所以沒事。」 那把鎖只證明存在一個安全連線。它對一個舊版本或一個被禁的密碼套件是否仍在後台被接受隻字不提——而那恰恰是這些檢查找出的缺口。
• 修了版本卻沒修密碼套件（或反過來）。 停用 TLS 1.0/1.1 不會自動移除 RC4 或 3DES，釘強密碼套件也不會自動停用舊版本。兩個都設——上面產生的設定會做到。
• 留著「legacy」或「老瀏覽器相容」開關開著。 許多主機和 CDN 有一個「為了相容」悄悄重新啟用被攻破版本或弱密碼套件的選項。它幾乎從不幫到一個真實訪客，卻直接導致這項發現。
• 忘了真正重載/重啟伺服器。 設定改動在 Web 伺服器被重載前不生效——這是一個「已修好」的網站重新檢測仍失敗的意外常見原因。
• 設定了一台伺服器卻沒設定全部。 如果你跑著負載平衡、多台 Web 伺服器，或分開的子網域（shop、blog、app），每個 TLS 端點都需要相同的設定——攻擊者瞄準的是最弱的那個。

要記住什麼

TLS 版本和密碼套件是你加密中真正撬動評分的那兩部分，而兩者歸根結柢都是關掉那些公開已被攻破多年的選項。修復免費，通常每台伺服器一行現代設定，而對一個普通訪客而言，它除了讓連線真正安全之外什麼都不改變。相關項目——壓縮、OCSP stapling、安全重協商——值得了解，但不會影響你的分數，而在任何現代設定上它們已被替你處理好。

常見問題