安全產品帶來的安全威脅——HTTPS檢查的風險

在很多人印象中，HTTPS就是安全的象徵，而為了對這些「安全」的流量進行檢查，很多安全產品，包括殺毒軟體和防火牆都具備HTTPS檢查的功能，通過這樣的功能排除其中的安全威脅。然而近日US-CERT卻發布了一則預警，TA17-075A，對部分HTTPS檢查產品發出安全預警，提到部分SSL/TLS攔截軟體未能執行有效驗證，或者未能充分傳遞驗證狀態，這可能被第三方發動中間人攻擊。

US-CERT為什麼要發出這個預警呢？讓我們來捋一捋最近發生的一些事情。

US-CERT專家發文稱SSL檢查有風險

首先是2015年初的時候，Superfish和PrivDog這兩款SSL檢查工具因為沒能正確驗證SSL引起了US-CERT專家的重視。專家稱因為沒能正確驗證SSL，導致用戶系統容易被攻擊者進行HTTPS嗅探。

接連幾個SSL檢查工具被曝存在相似問題后，US-CERT專家Will Dormann決定深入探究這個問題，發表了《SSL檢查的風險》一文，其中指出了一些問題：

1. 許多人並不了解SSL和TSL的功能；

2. SSL檢查產品比他想象的流行得多；

3. 許多有SSL檢查能力的應用都存在一些漏洞，可給用戶帶來風險；

4. 即便SSL檢查做得跟瀏覽器一樣安全，也會給用戶帶來一定風險。

下面我們一一來講。

背景知識

SSL和TLS的目的主要有兩個：一是認證與客戶端通信的伺服器，二是加密客戶端與伺服器之間發送的數據。有些人可能認為SSL和TLS能夠實現端到端加密，這種觀點是不對的。SSL和TLS只有在點到點的情況下才能實現安全認證和加密。我們先來看個例子，在本例中的點到點通信也可以被認為是端到端的通信：

客戶端能夠驗證安全通信，但只能和其通信的下一個點進行驗證。在上面的例子當中，客戶端直接和目標系統建立SSL/TLS連接。客戶端軟體通過系統上的大量根證書來驗證它連接的系統。至於這個系統是不是用戶預期的目標系統就是需要另作討論的話題了。

當用戶在瀏覽器當中載入受HTTPS保護的網站時，瀏覽器實際上只會驗證兩件事：網站是否提供了證書；證書是不是瀏覽器信任的根證書CA機構頒發的。實際上我們是在相信每個根CA機構都已盡全力來驗證你要連接的伺服器的身份。但是實際上有時候根CA機構會被騙。我們還相信每個根CA機構都能夠保護自己的系統。但是實際上有時候根CA會被盜用。

有關這些問題的更多細節，請參閱Moxie Marlinspike的博客文章《SSL與真實的未來》。

我們上面提到的Superfish和Privdog有什麼問題呢？它們會安裝一個新的受信根證書。

請注意這裡使用術語「可信」。 我們不是在討論PGP和GPG應用程序使用的信任網路的任何內容，在PGP中的「可信」是指使用個別密鑰的信任級別。 而「受信任的根CA證書」只是可以由客戶端軟體使用而不產生警告。 它與用戶對某事物的「信任」毫無關係。簡單來說，有了這個證書，客戶端軟體就不會發出安全警告提示你證書有問題。

這兩個工具都會安裝受信的根CA證書，不過好消息是他們的證書都明確寫明是來源於Superfish和Privdog。如果有軟體要把證書冒充成是由「VeriSign」等大機構發布的，寫成「VeriSign.」我們也無法防範。

假定有這樣一個場景，有人通過HTTPS訪問一家網站（因為要給出諸如用戶名和密碼這樣的敏感信息），裝了PrivDog或者Superfish。如果瀏覽器不對證書合法性作警告，最多也就意味著與用戶通訊的系統，獲得了受信root CA機構的證書，SuperFish和Privdog就是其中之一。

如果有人想要驗證某個證書是否由「真正」的證書機構發布的，比如說想要查看證書發行機構的指紋，所需的步驟在每個瀏覽器當中也各有不同。有些瀏覽器，比如微軟的IE，如果要查看證書還得先接受該證書，因此即便是安全專家可能也很難判斷是不是他想要連接的主機。

Superfish和Privdog這種主機層面的軟體僅僅是SSL檢查產品的一部分。Dormann發現，許多網路層面的應用和設備也能進行SSL檢查。安全網關、防火牆、數據丟失防護（DLP）產品和其他許多應用似乎都加入了SSL檢查的大軍。當然了，網路管理員要檢查受SSL/TLS保護的瀏覽可能有多種多樣的原因，但是很多人可能都沒有注意到，那些軟體的SSL檢查能力還不如瀏覽器，會帶來什麼樣的安全隱患不言而喻。我們來看看這個圖：

在上圖的通信過程中，客戶端只能驗證自己是在與SSL檢查軟體通信。客戶端並不清楚SSL檢查軟體用了什麼技術驗證SSL證書。而且更重要的是，SSL檢查軟體跟目標系統之間還有沒有額外的點，客戶端無法確定。SSL檢查軟體跟目標伺服器之間是否有攻擊者存在？客戶端無法知曉。由於這種不透明，客戶端只能相信SSL檢查軟體每一步都做到位了。但很不幸，SSL檢查軟體並沒有。

常見的SSL錯誤

分析了SSL檢查軟體之後，Dormann等人總結了這些軟體經常犯的一些錯誤：

1. 上游證書有效性驗證不充分

風險：客戶端無法知曉所連站點是否合法正規

2. 未告知客戶端上游證書驗證結果

風險：客戶端無法知曉所連站點是否合法正規

3. 證書規範名稱欄位信息過載

說明：有些SSL檢查軟體會通過證書的CN欄位，試圖將上游證書的有效性傳遞給客戶端。比如說，Komodia的SSL Digestor如果驗證伺服器端提供的證書無效，就會在證書的CN欄位開頭加上「verify_fail」字樣。這個技術其實會帶來很多問題。最明顯的錯誤就是傳遞給用戶的錯誤信息跟證書無效的原因沒有關係。

風險：客戶端系統的用戶可能不知道為什麼證書驗證沒有通過，或者甚至不知道驗證沒通過。攻擊者可以利用主題替代方案名稱（SAN）欄位令證書認證某一特定域，這樣瀏覽器就不會發出警告。

4. 用應用層反饋證書有效性

說明：有些SSL檢查工具會將網頁內容（比如HTML）提供給客戶端，並描述證書的問題。但客戶端軟體確定和展示證書的一般機制可能還是會提示證書沒有問題。

風險：用HTTPS訪問數據的並不一定是人。客戶端可能是用JSON數據跟伺服器通信的某個應用。這個問題還可能導致SSL有效性提示不一致。

5. 根據UA HTTP頭決定何時驗證證書

說明：有些軟體會根據客戶端提供的UA HTTP頭選擇性決定驗證上游證書的時間。這個技術可能是和上面的步驟一起使用的。

風險：使用這種機制就會導致部分客戶端都不能收到證書認證信息。

6. 預警之前建立通信

說明：有些SSL檢查工具檢測到證書錯誤后，會先把客戶端請求發送到伺服器，然後再給用戶發警告信息。

風險：攻擊者可能可以查看或修改敏感信息。

7. 使用相同根證書

說明：有些SSL檢查應用每次安裝的時候都使用相同的受信根證書。

風險：攻擊者可能獲得這些應用的私鑰，並且用這個受信根證書來給所有訪問網站簽名。

Dormann認為，即便SSL檢查應用不存在上述任何問題，客戶端還是無法獲知該應用信任了哪些根證書。使用SSL檢查軟體將阻礙或者完全阻止客戶端成功驗證其通信的伺服器。

後來Dormann用自己信任的中間人代理虛擬機CERT Tapioca檢測，發現有至少58個HTTPS檢查工具都存在上述安全問題。

谷歌、Mozilla專家聯合發布論文《HTTPS攔截的安全隱患》

基於上述的研究，來自密歇根大學、伊利諾伊大學厄本那-香檳分校、Mozilla、Cloudflare、Google、加州大學伯克利分校的研究人員決定對外界HTTPS攔截進行全面的研究，量化其流行程度和對現實世界安全的影響。

流量監控

研究人員首先對總體流量進行分析，通過三種渠道分別監控來自用戶的流量，然後分辨用戶是否使用了HTTPS流量監測工具。怎麼進行分辨呢？比如有一些安全產品在攔截流量後會修改User-Agent，研究人員進行分析就可以分辨哪些流量經過攔截，哪些沒有被攔截。他們發現Firefox更新連接有4.0%遭到攔截，6.2%的電商網站流量被攔截，10.9%的Cloudflare流量被攔截，這比之前估計的比例要高。

A. Firefox更新伺服器

相比其他瀏覽器，Firefox流量被攔截的比例更低，原因就在於Firefox有自帶的證書存儲，而IE、Chrome、Safari瀏覽器都使用了系統默認的證書存儲空間。因此，有些殺毒軟體如Avast不會攔截Firefox的流量。在企業環境中，儘管可以額外在Firefox的證書管理中添加證書，但這還是會增加麻煩，因此很多IT管理員就索性不再攔截Firefox流量。

研究人員還觀察到一些地理差異，比如瓜地馬拉有15%的Firefox更新伺服器流量被攔截，這比全球的平均比例要高3-4倍，原因是瓜地馬拉的移動運營商COMCEL處理了34.6%的更新流量而運營商對32.9%的流量進行了攔截。格陵蘭攔截率排在第二，主要是因為一個名為TELE Greenland的運營商的AS(自治系統)導致的，其中將近一般的流量都被Fortigate中間盒攔截。排名第三的韓國是使用手機最多的國家之一，大量的流量加上運營商AS系統中的攔截導致其攔截率較高。

B. 電商網站

研究人員觀察了25萬獨立訪客，並對HTTP User-Agent進行分析，識別出TLS握手時與UA瀏覽器不符的流量，結果觀察到6.8%的流量被攔截，另外0.9%可能被攔截但無法完全分類。通過對指紋進行分析發現，電商網站被攔截的流量中58%被反病毒軟體攔截，35%屬於企業代理，只有1.0%來自惡意軟體（如SuperFish）。攔截最多流量的三款殺毒軟體分別是Avast、Blue Coat和AVG，分別攔截了10.8%，9.1%和7.6%的流量。

Chrome瀏覽器處理了40.3%的TLS流量，其中8.6%被攔截，是被攔截比例最高的瀏覽器。而手機端Safari的瀏覽器是最低的，僅攔截了0.9%。研究人員還觀察到，Windows平台的流量攔截比例為8.3%–9.6%，而Mac平台則是2.1%，原因可能是大部分的企業用戶使用的是Windows，並且很多殺毒軟體是基於Windows的。

C. Cloudflare流量

通過檢查Clouldflare攔截的流量，研究人員觀察到10.9%的攔截率，握手環節中比例最高的指紋來自殺毒軟體Avast, AVG, Kaspersky和BitDefender。這與在電商網站得出的結論相互印證。

對安全性的影響

接下來，為了評估HTTPS檢查工具對安全的影響，研究人員制定了分級標準量化TLS客戶端安全性：

A: 最優

被攔截后的TLS連接與瀏覽器本身的安全性和性能一致，在對密碼套件區分等級時，研究人員使用了Chrome對「安全TLS」的定義。

B: 次優

連接使用了不理想的設置（比如非PFS密碼）但是不至於被已知的攻擊方法攻擊

C: 連接可被已知攻擊手法攻擊

連接能被已知的TLS攻擊手法（如BEAST，FREAK或Logjam）攻擊，接受768位的Diffie-Hellman密鑰或者支持RC4。

F: 嚴重缺陷

連接非常不安全，使用中間人攻擊就可以截獲並解密會話。比如產品不檢驗證書，或者提供不安全的密碼套件（如DES）。

不過值得注意的是很多瀏覽器引入了新的安全校驗機制如HSTS, HPKP, OneCRL/CRLSets, certificate transparency 驗證和OCSP must-staple。而測試的安全產品並不支持這些機制。從這個意義上說，即使獲得了「A」等級，Chrome或者Firefox瀏覽器還是要比這些HTTPS檢查工具更安全。

研究人員安裝了各類HTTPS檢查工具，包括企業代理、安全軟體、以及包含HTTPS攔截功能的惡意軟體，然後使用Chrome、IE、Firefox和Safari瀏覽器檢查如下項目：

1) TLS版本

檢查產品支持的最高版本TLS。客戶端最高支持TLS 1.1時評級為B，支持SSLv3評級為C，支持SSLv2評級為F。

2) 密碼套件

檢查客戶端問候消息中的密碼套件。把所有不支持Chrome的強TLS密碼的產品評級為B，握手時提供RC4的評級為C，支持其他更弱密碼如出口級密碼或者DES則評為F。

3) 證書驗證

使用一些不能信任的證書，包括過期的，自簽名的，或者簽名無效的證書。並且測試了一些由公開了密鑰的證書機構（如Superfish、eDell、Dell提供商的根證書）簽署的證書。如果HTTPS檢查工具接受了這些證書則評級為F。

4) 已知的TLS攻擊

檢查客戶端能否被BEAST、FREAK、Heartbleed和Logjam攻擊，檢查是否接受不夠安全的Diffie-Hellman密鑰，符合上述條件則評級為C。

企業中間件

研究結果顯示：

11/12款軟體的默認設置降低了連接的安全性；

5/12款存在嚴重漏洞；

10/12款接受RC4加密方式；

2/12款使用了出口級的密碼；

3/12款證書驗證存在問題；

客戶端安全軟體

測試的軟體幾乎都存在問題，並且研究人員注意到，殺毒軟體本身也存在漏洞，光Avast一款殺軟過去8個月就有10個漏洞被公開，其中還有一個漏洞能能夠被構造的證書執行遠程代碼。

惡意軟體

之前研究人員發現Komodia沒有驗證證書，而新的發現顯示NetFilter SDK也沒有進行驗證。因此這兩款軟體被評級為F。

對TLS流量的影響

研究人員觀察到，65%截獲的Firefox更新流量降低了安全性，37%存在嚴重漏洞。而27%的電商流量和45%的Cloudflare流量降低了安全性，能被黑客實現中間人攻擊的比例分別為18%和16%。

企業中間件

企業中間件攔截流量后62.3%的連接安全性降低了，而58.1%的連接存在嚴重漏洞。

在檢查Firefox流量時，研究人員調查了處理100K個連接的AS系統中攔截率最高、設備指紋出現次數最多的前25個。其中發現的機構包括金融公司、政府部門和教育機構。除了一家銀行以外，前25個AS中24個都降低了安全性。12個使用了出口級的密碼套件，可能被中間人攻擊。

存在問題的安全產品和廠商如下圖：

在論文結尾，研究人員針對目前HTTPS攔截的現狀提出了幾點意見：

安全社區需要達成共識

我們需要社區共識。安全社區對是否應該允許HTTPS攔截幾乎沒有共識。一方面，Chrome和Firefox通過允許本地安裝根證書繞過限制。而與此同時，採用新的協議特徵來進行更安全的攔截的討論又在IETF這樣的標準化小組裡遭到了大量反對。

想要找到長久有效的解決方案，安全社區必須要在「攔截檢查是否合理」這一問題上達成共識。

應該考慮驗證發生的環節

許多HTTPS安全功能希望通過混合HTTP和TLS層來實現端到端的連接，並通過在瀏覽器代碼中實現HTTPS功能，而不是在TLS庫中。例如，為了克服現有吊銷證書協議的弱點，Firefox有OneCRL機制，而Chrome有CRLSets。這兩種解決方案都能在典型的端到端情況下增加瀏覽器的安全性。然而，這些解決方案在TLS代理的存在下不提供任何保護，並且由於該解決方案不是TLS協議本身的一部分，所以TLS庫不實現這些安全檢查。比如，HPKP指令通過HTTP傳遞，而不是在TLS握手期間傳遞。瀏覽器無法對代理連接執行HPKP驗證，因為它們無法訪問目標證書，而代理又不會不執行驗證。雖然代理有能力執行額外的驗證，但卻沒有驗證。而且在許多情況下，廠商的精力都花費在正確部署現有TLS庫上，更不用說實現其他安全功能了。

如果我們希望瀏覽器執行額外的驗證，那麼代理就需要一種將連接詳細信息（即伺服器證書和加密參數）傳遞給瀏覽器的機制。如果要代理執行此驗證，我們需要在TLS中標準化這些驗證步驟，並使用流行的庫。但是現在的情況是最糟糕的——任何一方都不執行嚴格的驗證機制。

加密庫需要提供安全的默認值

幾個代理部署了經過很少修改定製的TLS庫。但這些庫的默認設置是有安全問題的。默認情況下，客戶端庫和Web伺服器應該優先考慮使其產品安全。OpenSSL最近決定刪除已知的密碼密碼套件，這樣的行為就值得讚賞。OpenSSL十年前就應該這麼做了。我們的社區應該繼續將默認選項限制為已經被證明安全的配置。

防毒軟體供應商應該重新考慮攔截HTTPS

防病毒軟體在本地運行，可以訪問本地文件系統，瀏覽器內存以及通過HTTPS載入的任何內容。由於他們可能會將TLS錯誤配置和RCE漏洞，我們強烈建議防病毒提供商重新考慮是否攔截HTTPS。

安全公司忽略了安全問題

我們希望通過披露現有產品的漏洞，我們可以鼓勵廠商修補問題。希望企業優先考慮其TLS實施的安全性，並考慮HTTPS生態系統發展的步伐以及是否能夠跟上必要的更新。

不要依賴客戶端配置

客戶端和伺服器端都需要選擇安全參數，而不是依靠一方來維持安全性。

管理員需要測試中間盒

鼓勵部署代理的管理員使用諸如Qualys SSL Lab的客戶端測試和等網站來測試其配置。

安全廠商應該更負責

正是在Google研究人員發布報告后，美國計算機應急響應小組(US-CERT)加入了聲浪。

US-CERT稱，「HTTPS檢查會削弱TLS的安全性，」而且告訴企業，如果他們需要對HTTPS進行審查，他們應該保證產品會「執行正確的TLS證書驗證」。

「由於HTTPS審查會管理協議、密鑰、證書，因此產品應該要執行必要的HTTPS驗證。」US-CERT的警告中稱。

不過也有安全專家表達了不同的看法，安全專家David Holmes在SecurityWeek發表文章，指責發布論文的研究人員。他認為攔截HTTPS的首要目標是防範惡意軟體。的確，很多企業會用到HTTPS攔截檢查，因為無論是現在還是將來，他們的首要威脅都是惡意軟體。很多惡意軟體已經開始使用HTTPS來規避檢測，因此要檢查惡意軟體別無他法。

筆者認為，安全廠商添加HTTPS檢查功能的初衷是為了進行安全檢查，想要像檢查HTTP網頁一樣對內容進行檢測，防止通信過程中的安全風險。現如今使用HTTPS的網站越來越多，瀏覽器廠商也在呼籲網站使用HTTPS協議，相關的證書的成本也在降低。

另一方面，HTTPS中的惡意流量也逐漸增多，甚至一些釣魚網站也使用了HTTPS協議。而黑客竊取HTTPS證書自行簽署網站證書，或者入侵HTTPS網站也是沒有可能。從這個意義上說，針對HTTPS內容的檢查十分必要。

2015年11月黑客竊取了世界銀行的SSL證書搭建針對PayPal的釣魚網站

但現實中，HTTPS檢查卻引入了新的安全問題，廠商對證書驗證的疏忽、使用了存在問題的庫都是產生問題的原因。整個事件帶給我們的啟示是，即便是安全廠商出品的安全產品也有可能存在安全問題，廠商在上線產品時應該進行嚴格的測試。

參考來源

The Risks of SSL Inspection

HTTPS Interception Weakens TLS Security | US-CERT

US Gov backs Google』s alarm: warns against HTTPS interception products – CSO | The Resource for Data Security Executives

CERT Tapioca | Vulnerability Analysis | The CERT Division – CERT. org

US-CERT』s Warning on SSL Interception vs. Security is a False Dichotomy | SecurityWeek.Com

The Security Impact of HTTPS Interception