清華大學教授段海新:網絡空間中的信任與沖突: Web PKI

數據隱私專題

清華大學教授段海新:網絡空間中的信任與沖突: Web PKI

我們今天已經離不開的電子商務等應用的安全建立在基于可信第三方的公鑰基礎（PKI）之上，而PKI的安全一定程度上仍然依賴于彼此之間的信任，而不是固若金湯的安全防范措施。

基督教中，上帝是萬能的，雖然人們看不見他、不知道他怎么工作，但是人們相信上帝從來不干壞事，也不會犯錯誤。信仰者不會問為什么，只需要相信，這就是“trust”。現代科學是質疑一切沒有證據的觀點，然而，盡管互聯網對抗各種攻擊增加了許多安全機制，但許多安全機制并非依賴于完美的、可證明的理論，追根究底仍然依賴于人們之間善意的合作與信任，目前的互聯網仍然依賴信任與合作才能保持安全可靠運行。

繼清華大學“網絡空間安全論壇”關于路由和域名的可信任討論之后，我將繼續討論公鑰基礎設施（PKI）中基本的信任機制和攻擊方式，并結合典型的案例分析互聯網基礎服務存在的風險。

Web PKI的信任機制

我們不信任路由、不信任DNS，因為攻擊者可以利用他們實現重定向、劫持、竊聽等攻擊；但是通常我們認為把流量加密以后就可以抵御這些攻擊，因為密碼協議的設計目標就是在不安全的網絡中也能實現安全的通信。現在，以密碼技術為基礎的TLS／SSL已經成了無處不在的安全應用的基石。

涉及到開放環境中的加密和認證，目前主流的商業應用中很難脫離可信第三方，在Web應用中也就是我們要討論的Web PKI，它是 SSL/TLS 的基石，X.509 證書是HTTPS 的關鍵要素。單獨看每一個CA，它所簽發證書的這個信任鏈就像是一棵樹。因為世界上有許多這樣的CA，所以整個互聯網的信任模型是一個森林狀的結構，如圖1所示。

圖1　CA森林狀的信任模型

我們現在所說的Web PKI是IETF PKIX 工作組開發的標準——Internet PKI或 Web PKI，其工作原理是：Subscriber提交 CSR(Certificate Signing Request)；RA/ CA驗證 Subscriber 身份；CA 簽發證書；在Web服務器上部署證書。

當通過瀏覽器訪問網站時：服務器在TLS握手過程中出具證書；瀏覽器驗證證書鏈的有效性；如果驗證通過，則協商會話秘鑰，繼續通信；如果不通過，彈出告警。

幾乎所有商務應用都依賴CA/HTTPS/ TLS，目前各種瀏覽器或操作系統預置了上百個Root CA，每個CA可以為無數個中間的CA簽發證書。這些Root CA和中間CA所簽發的證書都被視為合法。

然而，這些作為互聯網安全基石的CA是怎樣運行的，除了CA行業以外的其他人很少了解，他們像上帝一樣存在著。實際上，這些CA的運行標準或規范并沒有一個類似政府或聯合國一樣的官方機構來制定，而是來自于CAB論壇（CA/ Browser Forum）這樣一個完全由商業公司組成的志愿者組織。

Web PKI的常見問題

Web PKI從最初的設計到具體的實現都有一些問題，常見的問題包括以下幾種。

信任模型的問題

任何一個CA都可以為任何一個網站簽發證書，無需該網站的同意。拿到這種非授權的證書，可以構造一個假冒的網站，用戶的瀏覽器在訪問這種服務器時不會產生告警。CA簽發未經授權這種證書服務器證書的事件曾經發生過多起，其中包括：

2015年9月，谷歌發現世界最大的CA賽門鐵克簽發了幾個域名為www.google.com和google. com的證書，后來賽門鐵克開除了幾個違反公司操作程序的員工。2001年通過CA的審計發現VeriSign簽發了自稱來自微軟申請的代碼簽名證書；

2015年3月，谷歌威脅要從可信CA列表中刪除CNNIC CA的根證書，原因是CNNIC為埃及公司MCS Holding簽發的中級CA證書被部署到防火墻中，用于動態偽造任何網站證書并劫持所有HTTPS通信。

圖2　中間人通過偽造但有效的證書發起攻擊

2011年荷蘭CA DigiNotar被攻破，伊朗用戶在伊朗發現大量偽造的*.google. com證書。這一事件導致DigiNotar公司的根CA證書被主流瀏覽器或操作系統廠商刪除，并最終徹底破產。

證書申請過程中的驗證問題

多數CA是商業公司，證書申請流程自動化是他們能夠贏利的必由之路。因此，互聯網上多數服務器證書只是只驗證了域名的DV（Domain Validation）證書，CA通常只是驗證申請者的電子郵件屬于申請域名的管理員。然而，這種驗證也經常出問題。

Mike Zusman在2008年的DEFCON上展示了他從CA廠商Thawte騙取的一個Login.live.com的證書，因為Thawte認為郵箱sslcertificate@live.com應該屬于live. com的管理員，而實際上live.com是用戶可以自由申請的公用郵箱。

2015年類似的事情再度重演，一個芬蘭人用hostmaster@live.fi信箱從Comodo騙取了一個簽發給live.fi網站的證書。

用戶忽略告警

我們大家都在12306網站上購買火車票，而12306網站在用戶購票過程中，瀏覽器會彈出一個告警，告知用戶這是不受信任的CA所簽發的證書。

這種證書會有什么問題呢？如果這個環節中出現中間人，模仿12306，用戶訪問時同樣也會彈出一個告警，這導致用戶無從區分這個網站究竟是真實的還是來自攻擊者。PKI的目的是為了有一個可信的第三方之后，用戶可以通過是否彈出告警以區別好的網站和問題網站，而12306將有問題變成了一個常態，用戶真的遇到問題的時候，卻不知道實際上已經被攻擊了。

使用類似不可信證書的公共服務在中國遠不止12306，有些銀行也是。2013年的中美銀行網站的測量表明，美國前一百家銀行網站100%都使用可信證書，但是中國300多家銀行網站中，32%使用了不可信的CA簽發的證書。

公鑰證書簽名的弱密碼算法問題

在公鑰證書的簽名算法中使用MD5或SHA-1早在2005年前后就已經被證實為不安全的，但是仍有CA使用這兩種算法。2005年王小云教授展示了可以產生兩個同樣簽名的、不同的證書，2006年Stevens等人指出可以利用選擇前綴碰撞的方法構造了兩個ID不同、密鑰也不同的證書。直到2008年，他們用這種方法從一個商業CA真正獲得了一個假冒的CA證書，證實了這種攻擊在現實中是可行的。

2012年，在中東大規模傳播的火焰（Flame）病毒就是利用這種技術構造了一個微軟的證書，用它對補丁更新文件進行簽名，從而入侵Windows系統。

CDN中間人引發的信任威脅

現在主流的網站大部分都是通過CDN提供用戶服務，而通過CDN之后，互聯網原先端到端的模式，有了一個”中間人”——CDN本身。CDN 是以中間人的方式工作。原始網站是如何授權給中間的CDN 廠商、如何完成瀏覽器 - CDN - 原始網站之間的身份認證、秘鑰交換和數據保護，以及如何撤銷這種授權，無論學術界還是工業在以前都沒有系統性的考慮。

我們在世界上首先對CDN中的HTTPS部署進行了系統性的研究，研究成果發表在了安全領域的頂級學術會議Security & Privacy上。我們調研了Akamai、CloudFlare 等世界上主流的20個左右的 CDN 服務商，以及一萬多個支持 HTTPS 的熱門網站（同時也是上述20個 CDN 廠商的客戶），揭示出了當前HTTPS 在 CDN 部署中的許多問題。

首先是 CDN 節點和后臺源服務器之間的通信很容易受到中間人攻擊。我們測試了5個 CDN 廠商的后臺通信，發現盡管瀏覽器到 CDN 節點的通信使用 HTTPS加密，有的廠商使用明文的 HTTP 與后臺服務器進行通信；有的廠商雖然使用了HTTPS，卻不驗證證書的有效性；有的廠商雖然要求合法證書，但是卻不驗證證書的持有者是誰。

其次是瀏覽器和 CDN 節點之間的授權認證問題。我們發現很多 CDN 廠商要求源網站提交自己的公鑰證書和私鑰，這嚴重破壞了 PKI 安全信任的基本原則，即私鑰必須是嚴格保密、不能與第三方共享的。

另外，現有CDN廠商使用的方案——共享證書(shared certificate)或者客戶證書（custom certificate）也存在管理復雜、無法撤銷等問題。我們針對Alexa網站上Top 1M的網站，經過7個星期的測量，一共發生了67,290 次證書更換，其中有983個證書被撤銷，時間間隔在 0～5 天；有251 個證書被撤銷卻依然被使用。數據表明，約30% 的證書撤銷與更換只更改了密鑰，其他信息不變；73% 的證書更換后沒有被撤銷，絕大部分是 CDN 共享證書。

針對CDN的證書問題，國際互聯網工作組IETF也因為我們所指出的問題提出了標準草案。當然，每一種方案時至今日都并沒有完美地解決現在的問題，到目前為止，很多時候我們只能是信賴它，為了實現不可信環境下的可靠通信，我們還將要付出巨大的代價。

（本文根據清華大學段海新教授在2016年4月“網絡安全研究國際學術論壇”上的演講內容整理）