抽象：
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