SSL/TLS部署最佳實踐

原文：
https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf

譯者: Shawn the R0ck，(後面校正的自己加到後面)

SSL/TLS部署最佳實踐
作者：Ivan Ristić
version 1.3 (17 September 2013)
Copyright © 2012-2013 Qualys SSL Labs

抽象：

SSL/TLS是一個看似簡單的技術。非常容易部署和讓她跑起來，但是...她真的跑
起來了嗎。第一部分是真的---SSL很容易部署---但是她並不是那麼容易正確的部
署。爲了保證SSL提供安全性，用戶必須投入額外的精力去配置她。

2009年，我們在SSL Labs( https://www.ssllabs.com/)開始了相關工作，因爲我
們想明白SSL到底是在怎麼樣被使用，我們也打算彌補SSL缺乏易用的工具和文檔
的局面。我們進行了對SSL使用情況的完整調查，以及實現了在線檢測工具，但文
檔的缺乏依然存在。這份文檔是解決文檔問題的第一步。

我們的目標是讓已經不堪負重的系統管理員和程序員儘可能花費少量時間就能完
成安全站點的部署，正是因爲我們的目的如此，所以這份文檔可能不夠完備，因
爲只提供簡單實用容易理解的建議。對於那些想了解更多信息的讀者，可以看看
Section 6。


1. 私鑰和證書

SSL提供的安全質量完全依賴於私鑰，私鑰是安全證書的基礎，而安全證書則是驗
證服務器身份的重要因素。


1.1 使用2048位的私鑰

在你的所有服務器上使用2048位的RSA或者等價強度的ECDSA私鑰。密鑰的長度能
保證在一定時間能的安全，如果你已經使用1024位的RSA，儘量替換它們。如果你
的需求必須使用大於2048位的密鑰，請考慮ECDSA，因爲性能不錯。


1.2 保護私鑰

私鑰是重要的財產，儘可能限制能接觸到私鑰的人。推薦策略包括：

* 在一臺可信的計算機(Shawn注:加固過的物理機器)上生成私鑰和CSR(
  Certificate Signing Requests)。有一些CA會爲你生成密鑰和CSR，但這樣做
  明顯不妥。

* 受密碼保護的密鑰可以阻止在備份系統中被截獲

* 在發現被"日"後，撤回老的證書，生成新的密鑰和證書。

* 每年更新證書，總是使用最新的私鑰。


1.3 確保覆蓋到所有的主機名

確保你的證書覆蓋到你希望被訪問的站點。比如你的主站是www.example.com，但
你可能還有個www.example.net。你的目標就是避免無效證書警告，因爲那會讓你
的用戶產生疑惑從而影響對你的信任。

即使你的服務器只有一個主機名配置，也要記得你不能控制用戶是通過什麼路徑
訪問你的站點的，可能是其他的鏈接過來的。大部分情況下，你應該保證證書能
在沒有www前綴的情況下工作(比如，example.com和www.example.com)。所以這裏
原則就是：一個安全的WEB服務器應該有一個對所有DNS名稱解析正常的證書配置。

通配符證書( WIldcard certificates)有他們的應用場景，但應該避免使用，因
爲使用的話意味着暴露給很多人。換句話說，越少的人能訪問私鑰越好。


1.4 從靠譜的CA那裏獲得證書

選擇一個對待安全比較認真的可靠CA( Certificate Authority)，在選擇CA過程
中可以考慮以下因素：

* 對待安全的態度

  大多的CA都會有常規的安全審計，但是一些會更在意安全一些。搞清楚哪些對
  待安全的態度不是一件容易的事情，但一個簡單的做法是看看他們在安全方面
  的歷史狀況，他們如何應急被“日”以及如何從錯誤中學習。

* 實際的市場佔有率

* 業務重心

* 提供哪些服務

  在最底線的情況，你選擇的CA至少應該提供CRL( Certificate List)和OCSP(
  Online Certificate Status Protocol)撤回機制以及對於OCSP服務的性能。
  CA至少提供域名驗證和擴展證書驗證功能，最理想的情況可以讓你自己選擇公
  鑰算法，今天大多站點都使用RSA，但在未來ECDSA的性能優勢可能會變得重要。

* 證書管理選項

如果你的運維環境是需要

* 技術支持

選擇一個技術支持不錯的CA提供商


2. 配置

正確的SSL服務器配置才能保證站點的訪問者會信任你。


2.1 部署有效的證書鏈

在很多部署場景中，單一的服務器證書顯得不足，而多個證書則需要建立一個信
任鏈。一個常見的問題是正確的配置了服務器證書但卻搞忘了包含其他所需要的
證書。此外，雖然其他證書通常有很長的有效期，但她們也會過期，如果她們過
期就會影響整個鏈條。你的CA應該提供所有額外需要的證書。

一個無效證書鏈會導致服務器證書失效和客戶端瀏覽器報警告，這個問題有時候
不是那麼容易被檢測到，因爲有些瀏覽器可以自己重構一個完整的信任鏈而有些
則不行。

2.2 使用安全的協議

在SSL/TLS家族中有5種協議：S SLv2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2。
( Shawn注: TLS v1.3還在draft階段)

* SSL v2不安全，堅決不能用。( Shawn注: OpenSSL和GnuTLS當前的版本
  (2014.12.2)不支持SSL v2)

* SSL v3老而且過時，她缺乏一些密鑰特性，你不應該使用她除非有特別好的理
  由。( Shawn注: POODLE漏洞的出現徹底的廢掉了SSLv3，之前很多地方支持
  SSLv3的原因是兼容性問題，GnuTLS 3.4中將默認不支持SSLv3)

* TLS v1.0在很大程度上是安全的，至少沒有曝光重大的安全漏洞。

* TLS v1.1和TLS v1.2沒有著名的安全漏洞曝光。( Shawn注: 由於Edward
  Snowden曝光的內容有關於NSA“今天記錄，明天解密"的故事，所以大量的自由
  軟件社區和暗網使者們在過去1年中轉向了TLS v1.2的PFS)

TLS v1.2應該成爲你的主要協議。這個版本有巨大的優勢是因爲她有前面的版本
沒有的特性。如果你的服務器平臺不支持TLS v1.2，做個升級計劃吧。如果你的
服務提供商不支持TLS v1.2，要求他們升級。

對於那些老的客戶端，你還是需要繼續支持TLS v1.0和TLS v1.1。對於臨時的解
決方案，這些協議對於大多WEB站點依然被認爲是安全。


2.3 使用安全的Ciphersuites( Shawn注：真TM不知道該怎麼翻這個詞，意思是一堆密碼套裝，包括密鑰交換，加密算法，HMAC等的組合)

要安全的通信，首先得保證你是在和你想要通信的對端在通信。在SSL/TLS裏，
ciphersuites是定義你如何安全通信的。她們由一堆多樣化的組件組成。如果其
中一個組件被發現是不安全的，你應該切換刀其他的ciphersuites上。

你的目標應該是僅使用提供認證和128位加密或者更強的ciphersuites，其他都應該被排除掉：

* Anonymous Diffie-Hellman( ADH)套裝不提供認證
* NULL ciphersuites不提供加密
* 出口密鑰交換套裝( Export key exchange suites)使用容易被”日“的認證
* 使用強度不夠的ciphersuites(比如40或者56位的加密強度)也容易被”日“
* RC4比之前想象的要弱，你應該去除掉，或者計劃在未來去掉
* 3DES僅提供108位的安全(或者112位，看具體情況)，這也低於推薦的最低128位。你應該在未來去除她。


2.4 控制Ciphersuite選型

在SSL v3和後來的版本里，客戶端請求一個她支持的ciphersuites的列表，服務
器就從列表中選擇一個去跟客戶端做協商。不是所有的服務器都能很好處理這個
過程，一些服務器會選擇第一個請求列表中支持的ciphersuite，服務器選擇正確
的ciphersuites對於安全而言是極端重要的。


2.5 支持Forward Secrecy

Forward Secrecy是一個協議特性，她能開啓一個不依賴於服務器私鑰的安全會話。
不支持Forward Secrecy的ciphersuites，如果攻擊者記錄了通信內容，那麼她可
以在獲得私鑰後再解密出來( Shawn注: NSA就在幹這件事情，所以看出PFS有多重
要了吧)。你需要優先支持ECDHE套裝，可以以DHE套裝作爲協商回退
（ fallback)的備選方案。

2.6 關閉客戶端發起的重協商

在SSL/TLS裏，重協商允許一方停止交換數據而去重新協商一個安全會話。有一些
場景需要服務器發起重協商的請求，但客戶端並沒有發起重協商請求的必要。此
外，曾經出現過客戶端發起重協商請求的拒絕服務攻擊( Shawn註解: 每個重協商
請求服務器的計算量是客戶端的15倍)。

2.7 降低已知漏洞風險

沒有什麼是完全安全的，很多防護方案都會隨着時間推移成爲安全問題。最佳實
踐是隨時關注信息安全的世界在發生些什麼然後採取必要的措施。最簡單的是你
應該儘快的打每一個補丁。

下面的一些問題應該引起你的注意：

* 關閉不安全的重協商

  重協商特性在2009年時被發現是不安全的，協議需要更新。今天大部分廠商已
  經修復，至少提供了一個臨時方案。不安全的重協商很危險，因爲她很容易被
  利用。

* 關閉TLS壓縮
  
  2012年，CRIME攻擊[6]向我們展示了TLS壓縮所導致的信息泄漏可以被攻擊者用
  於還原部分的敏感數據(比如session cookies)。只有幾款客戶端支持TLS壓縮，
  所以即使關掉TLS壓縮也不會影響刀用戶體驗。

* 降低HTTP壓縮的信息泄漏風險
  
  2個CRIME的變種攻擊在2013年被曝光，不像CRIME針對TLS壓縮，TIME和BREACH
  漏洞是針對壓縮過的HTTP的返回包裏。HTTP壓縮對於很多公司都很重要，這個
  問題不容易發現，降低風險的方案可能需要修改業務代碼。

對於TIME和BREACH攻擊，只要攻擊者有足夠攻擊你的理由，那影響等同於CSRF。

* 關閉RC4

  RC4 cihpersuites已經被認爲是不安全而且應該關閉。目前，對於攻擊者最好
  的情況也需要百萬次的請求，因此危害是比較低的，我們期待未來有改進的的
  攻擊手法。

* 注意BEAST攻擊
  
  2011年曝光的BEAST攻擊是2004年的一個針對TLS 1.0或者更早版本但當時被認
  爲很難被利用的一個漏洞..............


3. 性能

這份文檔中安全是主要關注的點，但我們也必須注意刀性能的問題。一個安全服
務不能滿足性能需求無疑會被遺棄掉。然而，因爲SSL配置通常不會帶來很大的性
能開銷，我們把討論限定在常見的配置問題上。


3.1 不要使用強度過高的私鑰

在建立一條安全鏈接的密鑰協商的過程當中最大的開銷是由私鑰大小決定的，使
用密鑰過短會不安全，使用密鑰過長會的導致在一些場景無法忍受的性能下降。
對於大多的WEB站點，使用超過2048位的密鑰是浪費CPU和影響用戶體驗的。

3.2 確保正確使用Session重用

Session重用是一種性能優化技術，讓耗時的密碼計算操作在一段時間裏可重複使
用。一個關閉或者沒有Session重用機制的場景可能會導致嚴重性能下降。

3.3 使用持久性鏈接(HTTP)

今天的很多SSL過度開銷並非來自CPU的密碼計算操作，而是網絡延遲。一個SSL握
手是建立在TCP握手結束後，她需要更多的交換packet，爲了讓網絡延遲最小化，
你應該啓用HTTP持久化( keep-alives)，她讓你的用戶能一個TCP鏈接上發多次
HTTP請求。

3.4 爲公共資源開啓緩存(HTTP)

當開始使用SSL通信，瀏覽器會假設所有的流量都是敏感信息，也會把一些特定的
資源緩存到內存裏，但是一旦你關閉了瀏覽器，這些內容就丟失了。爲了得到性
能，爲一些資源開啓長期緩存，通過加入"Cache-Control: public"返回header給
瀏覽器標記爲公共資源（比如圖片）。

4. 應用設計（HTTP）

HTTP協議和WEB相關平臺在SSL誕生後仍然在不斷的進化。進化的結果就是有一些
今天包含的特性已經對加密不利。在這個Section裏，我們會羅列出這些特性，也
包括如何安全的使用她們。

4.1 100%的加密你的網站

事實上”加密是一個備選“的思想大概是今天最嚴重的安全問題之一。我們來看看
以下問題：

* 網站不需要SSL
* 網站有SSL但不是強制性的使用
* 網站混合了SSL和非SSL的內容，有時候甚至在相同的網頁上
* 網站編程錯誤導致SSL被”日“

如果你知道你自己在做什麼的話這些問題是可以有對抗方案的，最直接有效的方
式是強制所有的內容加密。


4.2 避免混合內容

混合內容的頁面是使用SSL的前提下但有些內容（比如JavaScript文件，圖片，
CSS）是通過非SSL的方式傳輸的。這些頁面不安全，比如中間人攻擊可以劫持這
些JavaScript的資源和用戶session。就算你遵循了前面的建議加密了所有的內容，
但也不排除來自第三方網站的資源是沒有加密的。

4.3 理解第三方站點

網站通常會通過JavaScript代碼來使用第三方的服務，Google Analytics是一個
應用廣泛的例子。內含的第三方代碼創建了一個隱式的信任鏈接讓第三方可以完
全控制你的網站。第三方本身可能並沒有惡意，但他們很容易成爲攻擊者的目標。
原因很簡單，如果一個大型第三方提供商被”日“，那攻擊者就可以利用這一路徑
去”日“她的使用者。

如果你採納了Section 4.2的建議，至少你的第三方鏈接在加密後可以防止中間人
攻擊。此外，你應該進一步去了解你的站點使用了哪些服務，搞明白其中的風險
你是否願意承擔。


4.4 安全Cookies
.................................


4.5 部署HSTS
.................................


4.6 關閉敏感內容的緩存

隨着基於雲的應用在增加，你必須得區分公開資源和敏感內容。.............


4.7 確保沒有其他漏洞

SSL不代表就安全，SSL的設計只是涉及安全的一個方面--通信過程中的保密性和
完整性，但還有其他威脅你必須面對。


5. Validation
...........參數調參和測試，也可以考慮使用在線工具：
https://www.ssllabs.com/ssltest/
...........


6. 高級議題

下面的這些議題超出了這份文檔的範疇，她們需要對SSL/TLS和公鑰架構(PKI)有
更深的理解，這些議題依然是受到爭議的。

* Extended Validation證書

  EV證書在簽發後進行離線檢測是更靠譜的證書。EV證書更難僞造，提供了更好
  的安全性。

* Public key pinning

  Public key pinning的設計是爲網站運維能限制哪些CA纔可以爲他們的網站籤
  發證書。這個特性是Google開發的，目前已經硬編碼到了Chrome瀏覽器裏面，
  並且證明是有效的。2個proposals:

1, Public Key Pinning Extension for HTTP:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning

2, Trust Assertions for Certificate Keys
http://tack.io/draft.html

* ECDSA私鑰

  事實上所有的網站都依賴於RSA私鑰。這個算法是WEB通信安全的基礎。因爲一
  些原因，我們正在從1024位轉向2048位的RSA密鑰。而增加密鑰長度可能會帶來
  性能問題。橢圓曲線密碼學(ECC)使用了不同的數學，能在較小的密鑰長度下有
  較強的安全性。RSA密鑰可以被ECDSA替代，目前只有少數的CA支持ECDSA，但我
  們期待未來會有更多。

* OCSP Stapling

  OCSP Stapling是改版的OCSP協議，允許撤回綁定證書自身的信息，直接服務於
  服務器和瀏覽器。不用像OCSP必須遠程驗證失效的證書，這提升了性能。


改動

這份文檔的最初的版本是在2012年2月24日發佈的。這個Section跟蹤了文檔修改
的時間，從1.3開始。

Version 1.3 (17 September 2013)
The following changes were made in this version:
• Recommend replacing 1024-bit certificates straight away.
• Recommend against supporting SSL v3.
• Remove the recommendation to use RC4 to mitigate the BEAST attack server-side.
• Recommend that RC4 is disabled.
• Recommend that 3DES is disabled in the near future.
• Warn about the CRIME attack variations (TIME and BREACH).
• Recommend supporting Forward Secrecy.
• Add discussion of ECDSA certificates.


感謝

爲了有價值的反饋和起草這份文檔，特別感謝Marsh Ray (PhoneFactor), Nasko
Oskov (Google), Adrian F. Dimcev和Ryan Hurst(GlobalSign)。也感謝其他慷
慨的分享關於信息安全和密碼學的人。這份文檔雖然是我寫的，但這些內容則來
自整個安全社區。

關於SSL Labs
.................

關於Qualys
................















[1] On the Security of RC4 in TLS and WPA (Kenny Paterson et al.; 13 March 2013)
http://www.isg.rhul.ac.uk/tls/

[2] Deploying Forward Secrecy (Qualys Security Labs; 25 June 2013)
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy

[3] Increasing DHE strength on Apache 2.4.x (Ivan Ristić’s blog; 15 August 2013)
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

[4] TLS Renegotiation and Denial of Service Attacks (Qualys Security Labs Blog, October 2011)
https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks

[5] SSL and TLS Authentication Gap Vulnerability Discovered (Qualys Security Labs Blog; November 2009)
https://community.qualys.com/blogs/securitylabs/2009/11/05/ssl-and-tls-authentication-gap-vulnerability-discovered

[6] CRIME: Information Leakage Attack against SSL/TLS (Qualys Security Labs Blog; September 2012)
https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls

[7] Defending against the BREACH Attack (Qualys Security Labs; 7 August 2013)
https://community.qualys.com/blogs/securitylabs/2013/08/07/defending-against-the-breach-attack

[8] Mitigating the BEAST attack on TLS (Qualys Security Labs Blog; October 2011)
https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

[9] Is BEAST Still a Threat? (Qualys Security Labs; 10 September 2013)
https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat