SSL/TLS 部署最佳實踐 v1.4

Reviewers: Lenx Wei

原文： SSL/TLS Deployment Best Practices

作者：Ivan Risti?

version 1.4 (8 December 2014)

Copyright ? 2012-2014 Qualys SSL Labs

摘要：

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以確保互操作性。

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。

• SSL v2不安全，堅決不能用。

• SSL v3用于HTTP已經被確認為不安全，用于其他協議時安全強度也不足。 它已經過時，不應該再被使用。

• TLS v1.0在很大程度上是安全的。當用于非HTTP協議時，我們還不知道存在任何 已知的重大安全漏洞。當用于HTTP協議時，我們能夠通過精心的服務器配置，來保證 它幾乎是安全的。

• TLS v1.1和TLS v1.2沒有已知的安全漏洞曝光。

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比之前想象的要弱，你應該在檢查好兼容問題后，盡快去除掉

• 3DES僅提供大約112位的安全系數，這也低于推薦的最低128位，不過依然足夠強。 但實踐中更大的問題是，她比其他替代算法要慢很多。所以，出于性能我們不推薦她， 但她依然可以放在加密套件的最后面，用來兼容非常陳舊的客戶端

2.4 控制加密套件選型

在SSL v3和后來的版本里，客戶端提交一個她支持的加密套件的列表，服務 器從列表中選擇一個去跟客戶端做協商，以構建一個安全的通信信道。 然而不是所有的服務器都能很好處理這個過程，一些服務器僅僅會簡單的從列表中選擇第一個。 讓服務器選擇正確的加密套件對于安全而言是極端重要的（詳見 Section 2.7）。

2.5 支持正向安全（Forward Secrecy）

正向安全是一個協議特性，它使得安全會話不依賴于服務器的私鑰。 當使用不支持正向安全的加密套件時，如果攻擊者記錄了通信內容，那么她可 以在未來獲得私鑰后，再解密先前的一切通信。你需要優先支持ECDHE套裝， 來讓瀏覽器選擇支持正向安全。 為了支持更廣泛的客戶端，可將DHE套件作為ECDHE的協商回退（fallback)方案。

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

在SSL/TLS里，重協商允許一方停止交換數據而去重新協商一個安全會話。有一些 場景需要服務器發起重協商的請求，但客戶端并沒有發起重協商請求的必要。此 外，曾經出現過客戶端發起重協商請求的拒絕服務攻擊。

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，絕大多數站點都 可以安全的實施。

3. 性能

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

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

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

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)。也感謝其他慷 慨的分享關于信息安全和密碼學的人。這份文檔雖然是我寫的，但這些內容則來 自整個安全社區。

關于SSL Labs ……………..

關于Qualys …………….

[1] SHA1 Deprecation Policy (Windows PKI blog, 12 November 2013) http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

[2] Gradually Sunsetting SHA-1 (The Chromium Blog, 5 September 2014) http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html

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

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

[5] 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

[6] 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

[7] 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

[8] 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

[9] 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

[10] Internet-Draft: Prohibiting RC4 Cipher Suites (A. Popov, 1 October 2014) http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/

[11] 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

[12] 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

[13] This POODLE bites: exploiting the SSL 3.0 fallback (Google Online Security Blog, 14 October 2014) http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html

[14] About EV SSL Certificates (CA/B Forum web site) https://www.cabforum.org/certificates.html

[T1] HAS THE RSA ALGORITHM BEEN COMPROMISED AS A RESULT OF BERNSTEIN’S PAPER? http://www.emc.com/emc-plus/rsa-labs/historical/has-the-rsa-algorithm-been-compromised.htm

[T2] Poodle Bites TLS https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls

[T3] Lucky Thirteen: Breaking the TLS and DTLS Record Protocols http://www.isg.rhul.ac.uk/tls/Lucky13.html