摘要：
SSL/TLS是一個看似簡單的技術。非常容易部署和讓她跑起來，但是…她真的跑 起來了嗎？第一部分是真的 —— SSL確實容易部署 —— 然而正確部屬她並不容易。 為了確保TLS提供安全性，系統管理員和開發者必須投入額外的精力，去配置伺服器和 編寫應用程式。
2009年，我們在SSL Labs開始了相關工作，因為我 們想明白TLS到底是在怎麼樣被使用，我們也打算彌補TLS缺乏易用的工具和文件 的局面。我們進行了對全域性TLS使用情況的完整調查，以及實現了線上檢測工具，但文 檔缺乏的問題依然存在。這份文件是解決這個問題過程中的一步。
我們的目標是讓已經不堪負重的系統管理員和程式設計師儘可能花費少量時間就能完 成安全站點或Web應用的部署，正是因為我們的目的如此，所以這份文件可能不夠完備，遺漏了 一些高階主題。因此，我們只提供簡單實用容易理解的建議。 對於那些想了解更多資訊的讀者，可以看看 Section 6。
1. 私鑰和證照
TLS提供的安全質量完全依賴於私鑰和證照。私鑰是安全的基礎，而證照則用於向訪問者表明 伺服器的身份。
1.1 使用2048位的私鑰
在你的所有伺服器上使用2048位的RSA，或者等價強度的256位ECDSA私鑰。金鑰的強度能 保證在相當長時間內的安全，如果你已經使用1024位的RSA，儘快替換它們。如果你 的安全需求必須使用大於2048位的金鑰，請考慮ECDSA，因為效能不錯。不過ECDSA的缺點 是小部分客戶端不支援，因此你有可能需要同時部署RSA和ECDSA以確保互操作性。
Lenx注：RSA 1024的強度相當於分組加密的80-96bit，已經被視為不安全。[T1]
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），但是其中一些會更重視 安全。搞清楚哪些更重視安全不是一件容易的事情，但一個可行的做法 是看看他們在安全方面的歷史狀況，他們如何響應攻擊事件以及如何從錯誤中學習。
- 足夠大的市場佔有率
滿足此因素的CA不太可能輕易撤銷所有證照，而這種事情過去曾發生在小的CA身上。
- 業務重心
如果一家機構的核心業務是CA，那麼一旦出現嚴重問題，他們將會受到嚴重影響。 因此這些CA不太可能因為追逐利潤而忽視證照部門的重要性。
- 提供哪些服務
在最底線的情況，你選擇的CA至少應該提供CRL( Certificate List)和OCSP( Online Certificate Status Protocol)這兩種召回機制，並且提供一個高效能的OCSP服務。 CA至少提供域名驗證和擴充套件證照驗證功能，最理想的情況可以讓你自己選擇公 鑰演算法(今天大多站點都使用RSA，但在未來ECDSA的效能優勢可能會變得重要。)
Shawn注：這裡作者可能指的是ECDH/ECDHE_ECDSA，即ECDH金鑰交換+ECDSA簽名的證照或者ECDH算出TLS的臨時session key+ECDSA簽名
- 證照管理選項
如果你的運維環境很複雜，需要一大堆的證照，那麼選擇一個能提供良好管理工具的 CA。
- 技術支援
選擇一個技術支援優秀的CA提供商。
1.5 選擇強演算法簽名證照
證照籤名的安全依賴於簽名私鑰的強度，以及所使用的雜湊函式強度。 今天大多數證照使用並不足夠安全的SHA1雜湊函式。業界正在逐漸 淘汰SHA1，而最後期限則是2016年末，這之後SHA1證照就不可接受了。
然而，Google Chrome在大限到來之前就開始對SHA1證照發出警告，如果你的證照 在2015年左右就要到期，你應該立刻替換這些證照。作為替代，你可以直奔SHA2 演算法家族。不過在你動手之前，你需要先看看你的使用者是否支援SHA2。一些舊客戶 端，例如 Windows XP SP2 的 IE 6 就不支援（但依然在一些國家和機構重度使用）。
2. 配置
使用正確的TLS伺服器配置，才能夠確保將你的信任憑證正確的展現給站點的訪問者， 確保只有安全的加密原語被使用，而且確保規避所有已知的安全風險。
2.1 部署有效的證照鏈
一個無效證照鏈會導致伺服器證照失效和客戶端瀏覽器報警告，這個問題有時候 不是那麼容易被檢測到，因為有些瀏覽器可以自己重構一個完整的信任鏈而有些 則不行。
在絕大多數部署場景中，僅伺服器自身一個證照是不夠的。一般需要多個證照建立一個信 任鏈。一個常見的問題是正確的配置了伺服器證照但卻忘了包含其他所需要的 證照。此外，雖然這些其他的證照通常有很長的有效期，但它們也會過期。而且一旦它們過 期就會使整個信任鏈作廢。你的CA應該向你提供所有額外需要的證照。
一個無效證照鏈會導致伺服器證照失效，並且導致客戶端瀏覽器報警。而實際上，這個問題有時候 難以診斷，因為有些瀏覽器可以自己重構一個完整的信任鏈而其他瀏覽器則不行。
2.2 使用安全的協議
在SSL/TLS家族中有5種協議：SSLv2, 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用於HTTP已經被確認為不安全，用於其他協議時安全強度也不足。 它已經過時，不應該再被使用。
Tom Li注: POODLE漏洞的出現徹底的廢掉了SSLv3，受其影響， 大量程式和庫徹底取消了對SSLv3的支援。其實之前很多地方支援SSLv3 的原因是相容性問題。
- TLS v1.0在很大程度上是安全的。當用於非HTTP協議時，我們還不知道存在任何 已知的重大安全漏洞。當用於HTTP協議時，我們能夠通過精心的伺服器配置，來保證 它幾乎是安全的。
- TLS v1.1和TLS v1.2沒有已知的安全漏洞曝光。
Shawn注: 由於Edward Snowden曝光的內容有關於NSA“今天記錄，明天解密”的故事， 所以大量的自由軟體社群和暗網使者們在過去1年中(2013.7–2014)轉向了TLS v1.2的PFS，2015年4月，[PCI-DSS v3.1] (https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf)規定所有SSL的版本以及早期TLS版本將於2016年6月30日後不再支援)
Lenx注：某一些TLS 1.x實現由於沒有正確實現對PADDING的校驗，同樣存在POODLE脆弱性問題。 這些有問題的TLS實現包括F5，A10，Checkpoint, Cisco等廠家的裝置。 同樣，Lucky 13攻擊一樣對老版本的OpenSSL, GnuTLS，F5等大量庫/裝置實現有效。 請確認打上補丁。[T2][T3]
TLS v1.2應該成為你的主要協議。這個版本有巨大的優勢是因為它有之前版本 沒有的特性。如果你的伺服器平臺（或中間裝置）不支援TLS v1.2，做個升 級計劃吧。如果你的服務提供商不支援TLS v1.2，要求他們升級。
對於那些老的客戶端，你還是需要繼續支援TLS v1.0和TLS v1.1。使用臨時的解 決方案（接下來會介紹），這些協議對於大多WEB站點依然被認為是足夠安全的。
2.3 使用安全的加密套件(Cipher Suite)
要安全的通訊，首先得保證你是和你想通訊的另一方直接通訊（而不是 冒充者或者存在能夠監聽的中間人），並且安全的交換資料。 在SSL/TLS裡，加密套件是定義你如何安全通訊的。 它們由一堆多樣化的元件組成，以確保安全。如果其中一個元件被發現是不安全的， 你應該切換到其他的元件上。
你的目標應該是僅使用128位或者更強的加密、認證套件，其他都應該被排除掉：
- Anonymous Diffie-Hellman (ADH) 套件不提供認證功能
- NULL cipher suites不提供加密
- 出口金鑰交換套件 (Export key exchange suites) 使用容易被破解的認證
- 使用強度不夠的加密演算法(比如40或者56位的加密強度)也容易被破解
- RC4比之前想象的要弱，你應該在檢查好相容問題後，儘快去除掉
Tom Li 注：2015年三月曝光的手段將RC4攻擊實用化，RC4堅決不要再用 [T4]
3DES僅提供大約112位的安全係數，這也低於推薦的最低128位，不過依然足夠強。 但實踐中更大的問題是，她比其他替代演算法要慢很多。所以，出於效能我們不推薦她， 但她依然可以放在加密套件的最後面，用來相容非常陳舊的客戶端
Tom Li 注：RC4安全漏洞曝光後，這是老舊客戶端唯一能用的演算法了
2.4 控制加密套件選型
在SSL v3和後來的版本里，客戶端提交一個她支援的加密套件的列表，服務 器從列表中選擇一個去跟客戶端做協商，以構建一個安全的通訊通道。 然而不是所有的伺服器都能很好處理這個過程，一些伺服器僅僅會簡單的從列表中選擇第一個。 讓伺服器選擇正確的加密套件對於安全而言是極端重要的（詳見 Section 2.7）。
2.5 支援正向安全（Forward Secrecy）
正向安全是一個協議特性，它使得安全會話不依賴於伺服器的私鑰。 當使用不支援正向安全的加密套件時，如果攻擊者記錄了通訊內容，那麼她可 以在未來獲得私鑰後，再解密先前的一切通訊。你需要優先支援ECDHE套裝， 來讓瀏覽器選擇支援正向安全。 為了支援更廣泛的客戶端，可將DHE套件作為ECDHE的協商回退（fallback)方案。
Shawn注: NSA就在幹這件事情，所以看出PFS有多重要了吧
2.6 關閉客戶端發起的重協商
在SSL/TLS裡，重協商允許一方停止交換資料而去重新協商一個安全會話。有一些 場景需要伺服器發起重協商的請求，但客戶端並沒有發起重協商請求的必要。此 外，曾經出現過客戶端發起重協商請求的拒絕服務攻擊。
Shawn註解: 每個重協商請求伺服器的計算量是客戶端的15倍
2.7 降低已知漏洞風險
沒有什麼是絕對安全的，很多防護方案都會隨著時間推移成為安全問題。最佳實 踐是隨時關注資訊保安的世界在發生些什麼，然後採取必要的措施。最簡單的是你 應該儘快的打每一個補丁。
下面的一些問題應該引起你的注意：
- 關閉不安全的重協商
重協商特性在2009年時被發現是不安全的，協議需要更新。今天大部分廠商已 經修復，至少提供了一個臨時方案。不安全的重協商很危險，因為她很容易被 利用，用來進行跨站請求偽造（CSFR）攻擊，並在某些情況下引發跨站指令碼（XSS） 攻擊。
- 關閉TLS壓縮
2012年，CRIME攻擊[6]向我們展示了TLS壓縮所導致的資訊洩漏可以被攻擊者用 於還原部分的敏感資料(比如session cookies)。只有幾款客戶端支援TLS 壓縮（而現在就更少了），所以即使關掉TLS壓縮，也完全不會遇到伺服器效能 問題。針對TLS壓縮的攻擊風險有限。
- 降低HTTP壓縮的資訊洩漏風險
2個CRIME的變種攻擊在2013年被曝光，不像CRIME針對TLS壓縮，TIME和BREACH 漏洞是針對壓縮過的HTTP響應。HTTP壓縮對於很多公司都很重要，這個 問題不容易解決。風險減緩方案可能需要修改業務程式碼。
對於TIME和BREACH攻擊，只要攻擊者有足夠攻擊你的理由，那影響等同於CSRF。
- 關閉RC4
RC4 cihpersuites已經被認為是不安全而且應該關閉。目前，對於攻擊者最好 的情況需要百萬次的請求，和大量的頻寬。因此危害是比較低的，不過我們期待 未來有改進的攻擊手法。在去除RC4之前，檢查這是否會影響現有的使用者；換句話 說，你應該查查有沒有僅支援RC4的客戶端。
- 注意BEAST攻擊
2011年曝光的BEAST攻擊是2004年的一個針對TLS 1.0或者更早版本但當時被認 為很難被利用的一個漏洞。一次成功的BEAST攻擊的影響約等於會話劫持。在一段時間內， 儘管問題出在客戶端，在服務端避免BEAST攻擊是合適的。但不幸的是， 伺服器需要使用RC4來避免問題，而這已經不再推薦了。因為這個原因，再加上 目前BEAST攻擊已經在大量客戶端中被解決了，我們不再推薦在服務端避免攻擊。 在有大量舊客戶端受BEAST攻擊影響的情況下，使用RC4和TLS 1.0也許更安全。 如何取捨需要在完全瞭解環境，建立威脅模型後小心決定。
- 關閉SSLv3
SSLv3受到2014年10月曝光的POODLE攻擊威脅。此攻擊很容易被利用來攻擊HTTP客戶端執行 JavaScript惡意程式。客戶端也很容易被攻擊者忽悠，從一個更安全的協議（如 TLSv1.2） 降級到不安全的SSLv3。因此最好的解決方案是在伺服器完全禁用SSLv3，絕大多數站點都 可以安全的實施。
Lenx注: 由於國內仍然存在大量IE 6客戶端，不支援TLS 1.x。目前如果必須 要支援SSLv3，那麼只能選擇RC4，並注意開啟TLS_FALLBACK_SCSV防止降級攻擊。 此外注意庫的及時升級，相關漏洞是一茬接著一茬的。
3. 效能
這份文件中安全是主要關注點，但我們也必須注意到效能的問題。一個安全服 務不能滿足效能需求無疑會被遺棄掉。然而，因為TLS配置通常不會帶來很大的性 能開銷，我們把討論限定在會導致嚴重效能下降的常見配置問題上。
3.1 不要使用強度過高的私鑰
在建立一條安全連線的金鑰協商的過程當中最大的開銷是由私鑰大小決定的，使 用金鑰過短會不安全，使用金鑰過長會的導致在一些場景無法忍受的效能下降。 對於大多的WEB站點，使用超過2048位的RSA/DHE金鑰，或者超過256位的ECDSA/ECDHE金鑰是浪 費CPU和影響使用者體驗的。
Shawn注：256-bit的ECC金鑰強度足夠勝任很長一段時間
3.2 確保正確使用Session重用
Session重用是一種效能優化技術，讓耗時的密碼計算操作的結果在一段時間裡可重複使 用。當Session重用機制失效時可能會導致嚴重效能下降。
3.3 使用永續性連結(HTTP)
今天絕大多數SSL開銷並非來自CPU密集型的密碼計算操作，而是網路延遲。一個TLS握 手是建立在TCP握手結束後，她需要交換更多的資料包。為了讓網路延遲最小化， 你應該啟用HTTP持久化( keep-alives)，從而讓你的使用者能在一個TCP連結上發多次 HTTP請求。
3.4 為公共資源開啟快取(HTTP)
當使用TLS通訊時，瀏覽器會假設所有的流量都是敏感資訊。瀏覽器會把一些特定的 資源快取到記憶體裡，但是一旦你關閉了瀏覽器，這些內容就丟失了。為了提升性 能，為一些資源開啟長期快取，通過加入”Cache-Control: public”返回header給 瀏覽器標記為公共資源（比如圖片）。
3.5 使用 OCSP Stapling
OCSP Staling是改版的OSCP協議，使得傳遞證照吊銷資訊成為TLS握手的一部分，直接 從伺服器傳遞到瀏覽器。因此，瀏覽器不再需要額外聯絡OCSP伺服器來驗證伺服器， 從而大幅降低連線耗時。
4. 應用設計（HTTP）
HTTP協議和WEB相關平臺在SSL誕生後仍然在不斷的進化。進化的結果就是有一些 今天包含的特性已經對加密不利。在這個Section裡，我們會羅列出這些特性，也 包括如何安全的使用它們。
4.1 100%的加密你的網站
事實上”加密是一個備選“的思想大概是今天最嚴重的安全問題之一。我們來看看 以下問題：
- 網站應該用TLS但沒用
- 網站有TLS但不是強制性的使用
- 網站混合了TLS和非TLS的內容，有時候甚至在相同的網頁上
- 網站程式設計錯誤導致TLS被攻陷
雖然如果你知道你自己在做什麼的話，這些問題大部分是可以避免的。然而一般而言， 唯一有效的方式是強制對所有的內容通訊進行加密 —— 沒有豁免。
4.2 避免混合內容
混合內容的頁面是已經使用TLS，但有些資源（比如JavaScript檔案，圖片， CSS）是通過非TLS的方式傳輸的。這些頁面不安全，主動的中間人攻擊者可以劫持這 些不受保護的JavaScript的資源，從而……例如劫持整個使用者會話。就算你遵循了前面的 建議加密了自己網站上所有的內容，但也不排除來自第三方網站的資源是沒有加密的。
4.3 理解信任第三方
網站通常會通過來自其他伺服器的JavaScript程式碼來使用第三方的服務，Google Analytics是一個 應用廣泛的例子。內含的第三方程式碼建立了一個隱式的信任鏈，讓第三方可以完 全控制你的網站。第三方本身可能並沒有惡意，但他們很容易成為攻擊者的目標。 原因很簡單，如果一個大型第三方提供商被攻陷，那攻擊者就可以利用這一路徑 導致所有使用它的人全都自動被攻陷。
如果你採納了Section 4.2的建議，至少你的第三方連結在加密後可以防止中間人 攻擊。此外，你應該進一步去了解你的站點使用了哪些服務，去除、替換或者承擔其中的 風險並繼續使用。
4.4 安全Cookies
為了安全，網站需要TLS。然而網站使用的cookies也要標記為安全。如果不能保護cookies，就 讓中間人攻擊者使用詭計獲取資訊成為可能，即使網站本身是100%加密的。
4.5 部署HSTS
HTTP嚴格傳輸安全（HSTS）是TLS協議的保護傘：它被設計成即使存在配置和實現錯誤的情況下，依然能保證安全。 設定一個簡單的響應header就能在支援HSTS的瀏覽器（目前是 Chrome、FireFox、Safari 和 Opear，IE 很快就會支援）上啟用保護。
HSTS的目的是很簡單的：在啟用之後，它就會禁止與網站進行任何不安全通訊，自動把明文連結轉換 成安全連結。一個額外的特性讓使用者不能無視證照警告（證照警告是 中間人攻擊的標誌，而研究表明大多數使用者都會無視警告，最好永遠不要讓使用者這麼做）
支援HSTS是一項能大幅度提高你網站TLS安全性的措施。新的網站應該在設計的時候就考慮到HSTS，而舊的 站點則應該儘快支援。
4.6 關閉敏感內容的快取
敏感內容應該被確實看作是敏感，只能傳送給該知道的一方。儘管代理伺服器看不到加密流量， 也不能把它共享給別人，但是隨著基於雲的應用在增加，你必須得小心區分公開資源和敏感內容。
4.7 確保沒有其他漏洞
TLS不代表就安全，TLS的設計只是涉及安全的一個方面–通訊過程中的保密性和 完整性——但還有其他威脅你必須面對。
5. Validation
在配置的時候可以進行調整的引數有一大堆，而你很難完全瞭解修改什麼會有什麼影響， 而有些時候改動可能是無意的；軟體升級也會悄悄引入變化。因此，我們建議使用一款 SSL/TLS評估工具來檢查你的配置是不是真的安全，並定期執行檢查保證你一直都安全。 對於公開站點，我們推薦使用SSLLab網站上的免費線上工具 它的“握手模擬”功能在實踐中非常有用，可以讓不同的TLS客戶端連線時時候的引數一清二楚。
6. 高階議題
下面的這些議題超出了這份文件的範疇，她們需要對SSL/TLS和公鑰架構(PKI)有 更深的理解，這些議題依然是受到爭議的。
- Extended Validation證照
EV證照是很靠譜的證照，只有經過充分的線下稽核後才給予頒發。證照的目的是明確 機構和它的對應線上網站的身份聯絡。EV證照更難偽造，提供了更好的安全性， 並且在瀏覽器上呈現給使用者時的待遇也更高。
- Public key pinning
Public key pinning的設計是為網站運維能限制哪些CA才可以為他們的網站籤 發證照。這個特性是Google開發的，目前已經硬編碼到了Chrome瀏覽器裡面， 並且證明對避免攻擊和引發大眾關注非常有效。在2014年，FireFox也加入了對 硬編碼pinning的支援。一個叫做《HTTP的Pubilc Key Pinning擴充套件》的標準已經 發展了很長時間了，很快講會發布。我們期待這個特性今後至少被主流瀏覽器支援。
- ECDSA私鑰
事實上所有的網站都依賴於RSA私鑰。這個演算法是WEB通訊安全的基礎。因為一 些原因，我們正在從1024位轉向2048位的RSA金鑰。而增加金鑰長度可能會帶來 效能問題。橢圓曲線密碼學(ECC)使用了不同的數學，能在較小的金鑰長度下有 較強的安全性。RSA金鑰可以被ECDSA替代，目前只有少數的CA支援ECDSA，但我 們期待未來會有更多。在遷移到ECDSA的時候，一個主要的問題是並非所有的 客戶端都支援它，如果你考慮使用ECDSA，應該確認它是否會影響使用者連線伺服器。 有些平臺支援雙金鑰部署，可以讓你同時使用RSA和ECDSA以適配所有的客戶端。
改動
這份文件的最初的版本是在2012年2月24日釋出的。這個Section跟蹤了文件修改 的時間，從1.3開始。
版本 1.3 (2013年9月17日) 此版本的改動有： • 推薦替換1024位證照 • 推薦不對SSLv3進行支援 • 刪去推薦使用RC4來服務端避免BEAST攻擊的內容 • 推薦禁用RC4 • 推薦在未來禁用3DES • 警告關於CRIME攻擊的變種（TIME和BREACH攻擊） • 推薦支援正向安全 • 加入對ECDSA證照的討論
版本 1.4 (2014年12月8日） 此版本的改動有： • 討論SHA1過時的問題，推薦遷移到SHA2系列演算法 • 推薦禁用SSLv3，提及POODLE攻擊 • 擴張Sectios 3.1，涵蓋DHE和ECDHE金鑰交換強度 • 推薦OCSP Stap
感謝
為了有價值的反饋和起草這份文件，特別感謝Marsh Ray (PhoneFactor), Nasko Oskov (Google), Adrian F. Dimcev和Ryan Hurst(GlobalSign)。也感謝其他慷 慨的分享關於資訊保安和密碼學的人。這份文件雖然是我寫的，但這些內容則來 自整個安全社群。