摘要：然而，最近被泄密的文件表明，美國國家安全局記錄了龐大的互聯網流量并且保留其中的加密信息供以后解密分析。的加密套件列表和在的調查中實際協商的加密套件。如果美國國家安全局獲得了這些網站的私鑰，除了谷歌以外所有的站點歷史通信都將被解密。

成千上萬的網站和個人依靠SSL來保護敏感信息的傳輸，比如密碼、信用卡信息和那些期望通過加密來保障隱私的個人信息。然而，最近被泄密的文件表明，美國國家安全局NSA記錄了龐大的互聯網流量并且保留其中的加密信息供以后解密分析。想監控互聯網加密流量的政府遠不止美國一個，沙特阿拉伯曾就SSL流量解密尋求過幫助，中國在今年一月份被指控對GitHub進行基于SSL的中間人攻擊，伊朗也被報道進行深度包檢測，但這些僅僅是冰山一角。

政府會考慮花大代價來記錄和存儲大量的加密流量,是因為如果用于流量加密的SSL私鑰將來可以獲得—可能是通過法律途徑,社會工程學,成功攻破了網站,亦或通過加密分析，那么所有這些網站的歷史流量會被瞬間解密。跟打開潘多拉魔盒一樣,作為一個點擊率高的站點,使用單一的密鑰就可以解密過去數以百萬人所加密過的流量。

有一個抵御的方法,那就是著名的完美轉發密鑰(PFS)。PFS采用即使主密鑰被泄露每個臨時會話密鑰也不會被泄露的方式連接SSL站點，所以當使用PFS的時候,一個SSL站點私鑰的泄漏不一定會暴露網站過去通信內容。PFS的安全在于雙方會話結束后丟棄共享密鑰（或經過一段適當時期后恢復會話）。

竊聽者想解密使用PFS的通信內容會面臨一個很艱巨的任務：每一個初始會話需要多帶帶攻擊。僅僅知道主密鑰而不知道臨時會話密鑰對數據解密沒有任何幫助。相反，當SSL連接沒有使用PFS的時候，用于加密后續會話通信的密鑰由SSL站點生成,而發送數據采用長期的公-私密鑰對。如果這個主密鑰被泄露，所有之前的加密會話很容易被解密。

PFS發明于1992年，比SSL協議早兩年誕生,一個理想的結果是希望SSL一開始就能使用PFS。然而,近20年后,大多數的SSL站點還沒有使用PFS。

PFS的使用依賴于瀏覽器和web服務器成功協商一個共同支持的PFS加密套件。如若可能，當PFS協商有利于瀏覽器用戶群體隱私時希望瀏覽器能提供所有它支持的PFS加密套件列表，另外存在的一個比較嚴重的PFS性能缺陷是需要在服務器端進行大范圍的查找工作。另一方面,只有少數瀏覽器被廣泛使用,如果政府為了更容易解密那些加密通信流量，它們會發揮其能限制PFS的使用，那么將會從限制web瀏覽器流行的數量開始。

Netcraft公司選了5個主流瀏覽器(IE、谷歌、火狐、Safari和Opera)，用?Netcraft公司六月份“SSL調查”所獲得的240萬個SSL站點來測試這五個瀏覽器對PFS的支持情況。結果顯示它們對PFS的支持差異顯著:IE自帶PFS的SSL連接操作只有很小一部分,然而,谷歌、Opera和火狐接近三分之一的SSL連接被PFS保護，Safari僅僅比IE好一點。具體結果如圖所示：

圖中加密套件來自每個瀏覽器與240萬個SSL站點連接時采用的，Opera的數據不包含它的TLS1.2加密套件。

IE確實比較薄弱因為它不支持任何同時使用RSA公鑰和非橢圓曲線DH密鑰交換的加密套件，而這兩種是PFS加密套件里最受歡迎的。IE支持比最常規使用的PFS加密套件優先級低的非PFS加密套件。說來也奇怪，IE居然支持采用罕見的DSS認證方法的DHE-DSS-AES256-SHA加密套件而不是很流行的DHE-RSA-AES256-SHA加密套件。

IE10的加密套件列表和在Netcraft的“SSL調查”中實際協商的加密套件。其中屬PFS的加密套件在表中用加粗字體顯示。

Safari瀏覽器支持較多的PFS加密套件，但是非橢圓曲線加密套件只是備用。當幾個非PFS加密套件有一個較高的權限時，web服務器為了顧及到瀏覽器的性能最終將選擇一個非PFS加密套件，即使web服務器自己支持某些（非橢圓曲線）PFS加密套件。

谷歌、火狐和Opera這三種瀏覽器支持PFS的效果比較好，在任意給定的優先級前更傾向于選擇PFS加密套件而不是非PFS加密，比如，Opera瀏覽器的性能列表抬頭標明：DHE-RSA-AES256-SHA,?DHE-DSS-AES256-SHA,?AES256-SHA,?DHE-RSA-AES128-SHA,?DHE-DSS-AES128-SHA,?AES128-SHA。Netcraft公司的測試僅僅包含了Opera瀏覽器的加密套件列表里現存的TLS1.2的加密套件，因此Opera瀏覽器實際使用PFS的SSL站點多于圖表中顯示的結果。

這些瀏覽器都沒有明顯的改變它們的用戶界面，只是用類似EV證書的綠色地址欄表示PFS的使用。谷歌瀏覽器和Opera瀏覽器用彈出框或對話框顯示使用的加密套件，使用用戶能理解的自然語言顯示，比如“[..]ECDHE_RSA作為密鑰交換機制”。

盡管瀏覽器盡力選擇PFS加密套件，但是具體使用哪種密鑰交換算法是由服務器決定的，服務器可能不支持任何的PFS，又或者選擇一個可以替代的加密套件（可能考慮到性能的問題）。使用Diffie-Hellman密鑰交換算法是以犧牲服務器的性能為代價的，因為它需要一個額外的算法來產生密鑰。

用幾個瀏覽器的密鑰組的性能進行排序，在Netcraft公司的“SSL調查”中至少有三分之二的SSL連接都沒有用PFS加密套件。測試結果如圖所示：

服務器對SSL站點的支持情況：每個瀏覽器分別與“SSL調查”中的240萬個SSL站點通信，按web服務器供應商分類。

Nginx是最初由俄羅斯人Igor?Sysoev寫的一個開源web服務器，默認使用強加密套件，在nginx的SSL性能文檔里有一些說明。除了IE和Safari，超過70%的SSL站點用nginx?web服務器時選擇使用PFS加密套件與瀏覽器通信。

在使用Apache服務器的SSL站點中頻繁使用PFS，大約三分之二的SSL站點在使用火狐、谷歌或者Opera訪問時都使用PFS加密套件。相反，微軟在服務器上對PFS的支持明顯欠缺，微軟的IIS和IE都很少用PFS加密套件，在IE與IIS之間使用PFS加密套件的SSL站點僅有0.01%?。

谷歌對一些自己的SSL站點采用PFS加密套件，但是好像托管在Google?App?Engine上的一些SSL站點并沒有使用PFS加密套件。

與棱鏡計劃相關公司使用PFS情況列表：PFS加密套件用綠色加粗字體顯示。

在棱鏡計劃受牽連的那些公司的SSL站點中，沒有任何一家的主流瀏覽器都使用PFS加密套件。當然，谷歌確實在大多數瀏覽器里使用了PFS加密套件，但不包括Opera瀏覽器。據說棱鏡計劃采用檢查SSL流量來運作,一直被認為十分不可能，因為報價需要花費2000萬美金。如果美國國家安全局獲得了這些網站的私鑰，除了谷歌以外所有的SSL站點歷史通信都將被解密。

其他一些著名SSL站點使用加密套件情況：選中的SSL站點協商的加密套件，PFS加密套件在上用綠色加粗字體顯示。

DuckDuckGo是一個搜索引擎，自愛德華·斯諾登披露它提倡使用匿名的隱私策略以來一直備受媒體關注。如果被DuckDuckGo用來加密的私鑰被泄露—比如它們其中的一個服務器被攻破，那么之前所有的日志記錄將被披露出來。DuckDuckGo也許是美國國安局特別感興趣的一個目標，也許是因為它的用戶量和流量相對于谷歌來講比較少的原因。

CloudFlare使用了和谷歌用的ECDHE?RC4或者AES類似的加密套件，但Opera瀏覽器例外。CloudFlare的SSL實現選項之一是從瀏覽器到CloudFlare服務器“靈活”的加密SSL流量，但如果內容不從緩存中返回，從CloudFlare連接到原來的網站將不使用SSL。相比試圖解密加密的內容，去攔截CloudFlare和原來的網站之間的未加密的流量通信可能會更容易。

Mega沒有用PFS加密套件，可能因為美國政府突然抄查Megaupload服務器的歷史舉動的原因。對服務器進行物理訪問，不難想象任何服務器的私鑰可能被摘錄，即使它保存在非持久性存儲器上。

陰謀論者對下面的情況可能不會感到驚訝：

微軟的IE、IIS和他們自己的一些web站點不使用PFS加密套件。蘋果在Safari瀏覽器對PFS的支持僅僅比微軟稍微好點。

俄羅斯是美國間諜的長期目標，也是nginx服務器（該web服務器經常使用PFS）的發源地。

幾乎所有與棱鏡計劃相牽連的公司運行的web站點都沒有使用PFS加密套件。

PFS沒有普及的原因讓陰謀論者津津樂道，其中一個原因可能是顧慮到網站的性能（善意的）：Mavrogiannopoulos報道稱用DHE-RSA加密套件比用普通的RSA算法連接SSL站點網站性能降低3倍。由于在瀏覽器中沒有清晰指出使用PFS加密套件，普通用戶也不會注意到網站沒有使用PFS加密套件，而如果網站的性能提高，普通用戶是能夠切身體會到的，所以普通的SSL站點會被說服放棄使用PFS提供的保護。

缺少了兩大主流瀏覽器和大多數web站點的支持，互聯網中大多數用戶并未得到PFS的安全保護。沒有PFS的保護，如果一個組織曾經被脅迫交出RSA私鑰—合法的或以其他方式，那么所有過去的SSL通信將處于危險中。然而PFS也不是萬能的，它使得對過去SSL通信的大規模解密變得困難的同時，也無法防止對單個會話的網絡攻擊。無論是否使用PFS，?SSL仍然是web站點用來在互聯網中安全傳輸數據防止竊聽者的一個重要工具（也許是最完善的）。

應該注意的是美國政府以及許多其他政府，頒發一些他們中意的SSL證書–盡管冒著擾亂程序規則和被其他有警覺性的用戶發現的危險，甚至谷歌的某些SSL站點。在主動攻擊可以實現，并且不可能被檢測到的狀態下，更應該注意被動攻擊竊聽者是否有利用非PFS的空檔。

用于SSL站點鏈接的加密套件的選擇由瀏覽器和SSL站點之間共同協商。瀏覽器和SSL站點都各自擁有自己所支持的SSL加密套件的優先級列表。在握手階段，瀏覽器發送一個ClientHello消息給SSL站點，其中包含一個在優先級列表里提供的所有的加密套件列表。?SSL站點首先選擇在收到的瀏覽器列表中自己也支持的瀏覽器列表中的第一個加密套件，或者忽略那個優先級順序而選擇在瀏覽器支持的自己列表中的第一個加密套件。如圖3所示，無論是加密套件A（如果優先考慮瀏覽器的優先順序）還是加密套件C（如果優先考慮web站點的優先順序）用于作為連接的加密套件是由SSL站點的設置而定。

瀏覽器與服務器加密套件協商過程

Diffie-Hellman密鑰交換（?DH）和它的變種經常用來協商通信雙方共享的臨時會話密鑰，密鑰本身從未被發送。每個會話密鑰在會話結束后被丟棄（?適當時期之后重新協商）。Diffie-Hellman的安全性依賴于離散對數問題的困難程度，即交換DH公鑰的同時使竊聽者難以確定具體的共享密鑰。?SSL加密套件支持常規短暫的Diffie-Hellman密鑰交換（通常稱為EDH或DHE?）和短暫的橢圓曲線的Diffie-Hellman?（?ECDHE?）?，它采用了跟EDH類似的體系，依賴于橢圓曲線離散對數問題的難度。?ECDHE基于橢圓曲線的密鑰交換，盡管速度更快，但只有少數SSL站點支持。

原文 SSL: Intercepted today, decrypted tomorrow
翻譯 IDF實驗室 李秀烈