摘要:然而,最近被泄密的文件表明,美國國家安全局記錄了龐大的互聯(lián)網(wǎng)流量并且保留其中的加密信息供以后解密分析。的加密套件列表和在的調(diào)查中實際協(xié)商的加密套件。如果美國國家安全局獲得了這些網(wǎng)站的私鑰,除了谷歌以外所有的站點歷史通信都將被解密。
成千上萬的網(wǎng)站和個人依靠SSL來保護(hù)敏感信息的傳輸,比如密碼、信用卡信息和那些期望通過加密來保障隱私的個人信息。然而,最近被泄密的文件表明,美國國家安全局NSA記錄了龐大的互聯(lián)網(wǎng)流量并且保留其中的加密信息供以后解密分析。想監(jiān)控互聯(lián)網(wǎng)加密流量的政府遠(yuǎn)不止美國一個,沙特阿拉伯曾就SSL流量解密尋求過幫助,中國在今年一月份被指控對GitHub進(jìn)行基于SSL的中間人攻擊,伊朗也被報道進(jìn)行深度包檢測,但這些僅僅是冰山一角。
政府會考慮花大代價來記錄和存儲大量的加密流量,是因為如果用于流量加密的SSL私鑰將來可以獲得—可能是通過法律途徑,社會工程學(xué),成功攻破了網(wǎng)站,亦或通過加密分析,那么所有這些網(wǎng)站的歷史流量會被瞬間解密。跟打開潘多拉魔盒一樣,作為一個點擊率高的站點,使用單一的密鑰就可以解密過去數(shù)以百萬人所加密過的流量。
有一個抵御的方法,那就是著名的完美轉(zhuǎn)發(fā)密鑰(PFS)。PFS采用即使主密鑰被泄露每個臨時會話密鑰也不會被泄露的方式連接SSL站點,所以當(dāng)使用PFS的時候,一個SSL站點私鑰的泄漏不一定會暴露網(wǎng)站過去通信內(nèi)容。PFS的安全在于雙方會話結(jié)束后丟棄共享密鑰(或經(jīng)過一段適當(dāng)時期后恢復(fù)會話)。
竊聽者想解密使用PFS的通信內(nèi)容會面臨一個很艱巨的任務(wù):每一個初始會話需要多帶帶攻擊。僅僅知道主密鑰而不知道臨時會話密鑰對數(shù)據(jù)解密沒有任何幫助。相反,當(dāng)SSL連接沒有使用PFS的時候,用于加密后續(xù)會話通信的密鑰由SSL站點生成,而發(fā)送數(shù)據(jù)采用長期的公-私密鑰對。如果這個主密鑰被泄露,所有之前的加密會話很容易被解密。
PFS發(fā)明于1992年,比SSL協(xié)議早兩年誕生,一個理想的結(jié)果是希望SSL一開始就能使用PFS。然而,近20年后,大多數(shù)的SSL站點還沒有使用PFS。
PFS的使用依賴于瀏覽器和web服務(wù)器成功協(xié)商一個共同支持的PFS加密套件。如若可能,當(dāng)PFS協(xié)商有利于瀏覽器用戶群體隱私時希望瀏覽器能提供所有它支持的PFS加密套件列表,另外存在的一個比較嚴(yán)重的PFS性能缺陷是需要在服務(wù)器端進(jìn)行大范圍的查找工作。另一方面,只有少數(shù)瀏覽器被廣泛使用,如果政府為了更容易解密那些加密通信流量,它們會發(fā)揮其能限制PFS的使用,那么將會從限制web瀏覽器流行的數(shù)量開始。
瀏覽器對PFS的支持現(xiàn)狀Netcraft公司選了5個主流瀏覽器(IE、谷歌、火狐、Safari和Opera),用?Netcraft公司六月份“SSL調(diào)查”所獲得的240萬個SSL站點來測試這五個瀏覽器對PFS的支持情況。結(jié)果顯示它們對PFS的支持差異顯著:IE自帶PFS的SSL連接操作只有很小一部分,然而,谷歌、Opera和火狐接近三分之一的SSL連接被PFS保護(hù),Safari僅僅比IE好一點。具體結(jié)果如圖所示:
圖中加密套件來自每個瀏覽器與240萬個SSL站點連接時采用的,Opera的數(shù)據(jù)不包含它的TLS1.2加密套件。
IE確實比較薄弱因為它不支持任何同時使用RSA公鑰和非橢圓曲線DH密鑰交換的加密套件,而這兩種是PFS加密套件里最受歡迎的。IE支持比最常規(guī)使用的PFS加密套件優(yōu)先級低的非PFS加密套件。說來也奇怪,IE居然支持采用罕見的DSS認(rèn)證方法的DHE-DSS-AES256-SHA加密套件而不是很流行的DHE-RSA-AES256-SHA加密套件。
Browser?priority | Cipher?Suite | Real-world?usage?in?SSL?Survey |
---|---|---|
1 | AES128-SHA | 63.52% |
2 | AES256-SHA | 2.21% |
3 | RC4-SHA | 17.12% |
4 | DES-CBC3-SHA | 0.41% |
5 | ECDHE-RSA-AES128-SHA | 0.08% |
6 | ECDHE-RSA-AES256-SHA | 0.21% |
7 | ECDHE-ECDSA-AES128-SHA | 0.00% |
8 | ECDHE-ECDSA-AES256-SHA | 0.00% |
9 | DHE-DSS-AES128-SHA | 0.00% |
10 | DHE-DSS-AES256-SHA | 0.00% |
11 | EDH-DSS-DES-CBC3-SHA | 0.00% |
12 | RC4-MD5 | 16.46% |
IE10的加密套件列表和在Netcraft的“SSL調(diào)查”中實際協(xié)商的加密套件。其中屬PFS的加密套件在表中用加粗字體顯示。
Safari瀏覽器支持較多的PFS加密套件,但是非橢圓曲線加密套件只是備用。當(dāng)幾個非PFS加密套件有一個較高的權(quán)限時,web服務(wù)器為了顧及到瀏覽器的性能最終將選擇一個非PFS加密套件,即使web服務(wù)器自己支持某些(非橢圓曲線)PFS加密套件。
谷歌、火狐和Opera這三種瀏覽器支持PFS的效果比較好,在任意給定的優(yōu)先級前更傾向于選擇PFS加密套件而不是非PFS加密,比如,Opera瀏覽器的性能列表抬頭標(biāo)明:DHE-RSA-AES256-SHA,?DHE-DSS-AES256-SHA,?AES256-SHA,?DHE-RSA-AES128-SHA,?DHE-DSS-AES128-SHA,?AES128-SHA。Netcraft公司的測試僅僅包含了Opera瀏覽器的加密套件列表里現(xiàn)存的TLS1.2的加密套件,因此Opera瀏覽器實際使用PFS的SSL站點多于圖表中顯示的結(jié)果。
這些瀏覽器都沒有明顯的改變它們的用戶界面,只是用類似EV證書的綠色地址欄表示PFS的使用。谷歌瀏覽器和Opera瀏覽器用彈出框或?qū)υ捒蝻@示使用的加密套件,使用用戶能理解的自然語言顯示,比如“[..]ECDHE_RSA作為密鑰交換機(jī)制”。
Web服務(wù)器對PFS的支持情況盡管瀏覽器盡力選擇PFS加密套件,但是具體使用哪種密鑰交換算法是由服務(wù)器決定的,服務(wù)器可能不支持任何的PFS,又或者選擇一個可以替代的加密套件(可能考慮到性能的問題)。使用Diffie-Hellman密鑰交換算法是以犧牲服務(wù)器的性能為代價的,因為它需要一個額外的算法來產(chǎn)生密鑰。
用幾個瀏覽器的密鑰組的性能進(jìn)行排序,在Netcraft公司的“SSL調(diào)查”中至少有三分之二的SSL連接都沒有用PFS加密套件。測試結(jié)果如圖所示:
服務(wù)器對SSL站點的支持情況:每個瀏覽器分別與“SSL調(diào)查”中的240萬個SSL站點通信,按web服務(wù)器供應(yīng)商分類。
Nginx是最初由俄羅斯人Igor?Sysoev寫的一個開源web服務(wù)器,默認(rèn)使用強(qiáng)加密套件,在nginx的SSL性能文檔里有一些說明。除了IE和Safari,超過70%的SSL站點用nginx?web服務(wù)器時選擇使用PFS加密套件與瀏覽器通信。
在使用Apache服務(wù)器的SSL站點中頻繁使用PFS,大約三分之二的SSL站點在使用火狐、谷歌或者Opera訪問時都使用PFS加密套件。相反,微軟在服務(wù)器上對PFS的支持明顯欠缺,微軟的IIS和IE都很少用PFS加密套件,在IE與IIS之間使用PFS加密套件的SSL站點僅有0.01%?。
谷歌對一些自己的SSL站點采用PFS加密套件,但是好像托管在Google?App?Engine上的一些SSL站點并沒有使用PFS加密套件。
SSL與棱鏡計劃有什么關(guān)系?與棱鏡計劃相關(guān)公司使用PFS情況列表:PFS加密套件用綠色加粗字體顯示。
在棱鏡計劃受牽連的那些公司的SSL站點中,沒有任何一家的主流瀏覽器都使用PFS加密套件。當(dāng)然,谷歌確實在大多數(shù)瀏覽器里使用了PFS加密套件,但不包括Opera瀏覽器。據(jù)說棱鏡計劃采用檢查SSL流量來運(yùn)作,一直被認(rèn)為十分不可能,因為報價需要花費(fèi)2000萬美金。如果美國國家安全局獲得了這些網(wǎng)站的私鑰,除了谷歌以外所有的SSL站點歷史通信都將被解密。
其他一些著名的SSL站點其他一些著名SSL站點使用加密套件情況:選中的SSL站點協(xié)商的加密套件,PFS加密套件在上用綠色加粗字體顯示。
DuckDuckGo是一個搜索引擎,自愛德華·斯諾登披露它提倡使用匿名的隱私策略以來一直備受媒體關(guān)注。如果被DuckDuckGo用來加密的私鑰被泄露—比如它們其中的一個服務(wù)器被攻破,那么之前所有的日志記錄將被披露出來。DuckDuckGo也許是美國國安局特別感興趣的一個目標(biāo),也許是因為它的用戶量和流量相對于谷歌來講比較少的原因。
CloudFlare使用了和谷歌用的ECDHE?RC4或者AES類似的加密套件,但Opera瀏覽器例外。CloudFlare的SSL實現(xiàn)選項之一是從瀏覽器到CloudFlare服務(wù)器“靈活”的加密SSL流量,但如果內(nèi)容不從緩存中返回,從CloudFlare連接到原來的網(wǎng)站將不使用SSL。相比試圖解密加密的內(nèi)容,去攔截CloudFlare和原來的網(wǎng)站之間的未加密的流量通信可能會更容易。
Mega沒有用PFS加密套件,可能因為美國政府突然抄查Megaupload服務(wù)器的歷史舉動的原因。對服務(wù)器進(jìn)行物理訪問,不難想象任何服務(wù)器的私鑰可能被摘錄,即使它保存在非持久性存儲器上。
總結(jié)陰謀論者對下面的情況可能不會感到驚訝:
微軟的IE、IIS和他們自己的一些web站點不使用PFS加密套件。蘋果在Safari瀏覽器對PFS的支持僅僅比微軟稍微好點。
俄羅斯是美國間諜的長期目標(biāo),也是nginx服務(wù)器(該web服務(wù)器經(jīng)常使用PFS)的發(fā)源地。
幾乎所有與棱鏡計劃相牽連的公司運(yùn)行的web站點都沒有使用PFS加密套件。
PFS沒有普及的原因讓陰謀論者津津樂道,其中一個原因可能是顧慮到網(wǎng)站的性能(善意的):Mavrogiannopoulos報道稱用DHE-RSA加密套件比用普通的RSA算法連接SSL站點網(wǎng)站性能降低3倍。由于在瀏覽器中沒有清晰指出使用PFS加密套件,普通用戶也不會注意到網(wǎng)站沒有使用PFS加密套件,而如果網(wǎng)站的性能提高,普通用戶是能夠切身體會到的,所以普通的SSL站點會被說服放棄使用PFS提供的保護(hù)。
缺少了兩大主流瀏覽器和大多數(shù)web站點的支持,互聯(lián)網(wǎng)中大多數(shù)用戶并未得到PFS的安全保護(hù)。沒有PFS的保護(hù),如果一個組織曾經(jīng)被脅迫交出RSA私鑰—合法的或以其他方式,那么所有過去的SSL通信將處于危險中。然而PFS也不是萬能的,它使得對過去SSL通信的大規(guī)模解密變得困難的同時,也無法防止對單個會話的網(wǎng)絡(luò)攻擊。無論是否使用PFS,?SSL仍然是web站點用來在互聯(lián)網(wǎng)中安全傳輸數(shù)據(jù)防止竊聽者的一個重要工具(也許是最完善的)。
應(yīng)該注意的是美國政府以及許多其他政府,頒發(fā)一些他們中意的SSL證書–盡管冒著擾亂程序規(guī)則和被其他有警覺性的用戶發(fā)現(xiàn)的危險,甚至谷歌的某些SSL站點。在主動攻擊可以實現(xiàn),并且不可能被檢測到的狀態(tài)下,更應(yīng)該注意被動攻擊竊聽者是否有利用非PFS的空檔。
關(guān)于PFS協(xié)商的一些細(xì)節(jié)用于SSL站點鏈接的加密套件的選擇由瀏覽器和SSL站點之間共同協(xié)商。瀏覽器和SSL站點都各自擁有自己所支持的SSL加密套件的優(yōu)先級列表。在握手階段,瀏覽器發(fā)送一個ClientHello消息給SSL站點,其中包含一個在優(yōu)先級列表里提供的所有的加密套件列表。?SSL站點首先選擇在收到的瀏覽器列表中自己也支持的瀏覽器列表中的第一個加密套件,或者忽略那個優(yōu)先級順序而選擇在瀏覽器支持的自己列表中的第一個加密套件。如圖3所示,無論是加密套件A(如果優(yōu)先考慮瀏覽器的優(yōu)先順序)還是加密套件C(如果優(yōu)先考慮web站點的優(yōu)先順序)用于作為連接的加密套件是由SSL站點的設(shè)置而定。
瀏覽器與服務(wù)器加密套件協(xié)商過程
選擇加密套件算法介紹Diffie-Hellman密鑰交換(?DH)和它的變種經(jīng)常用來協(xié)商通信雙方共享的臨時會話密鑰,密鑰本身從未被發(fā)送。每個會話密鑰在會話結(jié)束后被丟棄(?適當(dāng)時期之后重新協(xié)商)。Diffie-Hellman的安全性依賴于離散對數(shù)問題的困難程度,即交換DH公鑰的同時使竊聽者難以確定具體的共享密鑰。?SSL加密套件支持常規(guī)短暫的Diffie-Hellman密鑰交換(通常稱為EDH或DHE?)和短暫的橢圓曲線的Diffie-Hellman?(?ECDHE?)?,它采用了跟EDH類似的體系,依賴于橢圓曲線離散對數(shù)問題的難度。?ECDHE基于橢圓曲線的密鑰交換,盡管速度更快,但只有少數(shù)SSL站點支持。
原文 SSL: Intercepted today, decrypted tomorrow
翻譯 IDF實驗室 李秀烈
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/11098.html
摘要:將截獲的密文用自己偽造證書的私鑰解開,獲得并計算得到通信用的對稱密鑰。為何要用https? http協(xié)議的缺點 通信使用明文,內(nèi)容可能被竊聽(重要密碼泄露) 不驗證通信方身份,有可能遭遇偽裝(跨站點請求偽造) 無法證明報文的完整性,有可能已遭篡改(運(yùn)營商劫持) 用https能解決這些問題么? https是在http協(xié)議基礎(chǔ)上加入加密處理和認(rèn)證機(jī)制以及完整性保護(hù),即http+加密+認(rèn)證+完...
摘要:為什么會認(rèn)為網(wǎng)站不安全原因是該網(wǎng)站采用了協(xié)議。使用協(xié)議的網(wǎng)站,在數(shù)據(jù)傳輸?shù)倪^程中會對用戶數(shù)據(jù)進(jìn)行加密即加密,經(jīng)過加密的數(shù)據(jù)再進(jìn)行網(wǎng)絡(luò)傳輸,那么即使是被第三者截獲也能保證用戶數(shù)據(jù)的安全和數(shù)據(jù)的完整性。 現(xiàn)在你只要使用Chrome瀏覽器訪問任何HTTP網(wǎng)站,Chrome都會在地址欄上顯示不安全的警告。為什么Chrome會認(rèn)為網(wǎng)...
摘要:明文協(xié)議的缺陷是導(dǎo)致數(shù)據(jù)泄露數(shù)據(jù)篡改流量劫持釣魚攻擊等安全問題的重要原因。不驗證通信方的身份,因此有可能遭遇偽裝協(xié)議中的請求和響應(yīng)不會對通信方進(jìn)行確認(rèn)。數(shù)字簽名能確定消息的完整性證明數(shù)據(jù)是否未被篡改過。 近幾年,互聯(lián)網(wǎng)發(fā)生著翻天覆地的變化,尤其是我們一直習(xí)以為常的HTTP協(xié)議,在逐漸的被HTTPS協(xié)議所取代,在瀏覽器、搜索引擎、CA機(jī)構(gòu)、大型互聯(lián)網(wǎng)企業(yè)的共同促進(jìn)下,互聯(lián)網(wǎng)迎來了HTTP...
摘要:明文協(xié)議的缺陷是導(dǎo)致數(shù)據(jù)泄露數(shù)據(jù)篡改流量劫持釣魚攻擊等安全問題的重要原因。也就是說加上加密處理和認(rèn)證以及完整性保護(hù)后即是。數(shù)字簽名能確定消息的完整性證明數(shù)據(jù)是否未被篡改過。 前言 近幾年,互聯(lián)網(wǎng)發(fā)生著翻天覆地的變化,尤其是我們一直習(xí)以為常的HTTP協(xié)議,在逐漸的被HTTPS協(xié)議所取代,在瀏覽器、搜索引擎、CA機(jī)構(gòu)、大型互聯(lián)網(wǎng)企業(yè)的共同促進(jìn)下,互聯(lián)網(wǎng)迎來了HTTPS加密時代,HTTPS將...
摘要:明文協(xié)議的缺陷是導(dǎo)致數(shù)據(jù)泄露數(shù)據(jù)篡改流量劫持釣魚攻擊等安全問題的重要原因。也就是說加上加密處理和認(rèn)證以及完整性保護(hù)后即是。數(shù)字簽名能確定消息的完整性證明數(shù)據(jù)是否未被篡改過。 前言 近幾年,互聯(lián)網(wǎng)發(fā)生著翻天覆地的變化,尤其是我們一直習(xí)以為常的HTTP協(xié)議,在逐漸的被HTTPS協(xié)議所取代,在瀏覽器、搜索引擎、CA機(jī)構(gòu)、大型互聯(lián)網(wǎng)企業(yè)的共同促進(jìn)下,互聯(lián)網(wǎng)迎來了HTTPS加密時代,HTTPS將...
閱讀 3866·2023-04-25 17:45
閱讀 3506·2021-09-04 16:40
閱讀 1069·2019-08-30 13:54
閱讀 2199·2019-08-29 12:59
閱讀 1468·2019-08-26 12:11
閱讀 3350·2019-08-23 15:17
閱讀 1576·2019-08-23 12:07
閱讀 3946·2019-08-22 18:00