0x00 前言

---

在前面的章節我們討論了部分SSL/TLS握手協議、記錄協議中存在的安全問題，針對它們的攻擊以及相應的加固方案。在SSL/TLS所依賴的PKI體系中，證書吊銷過程同樣對SSL通訊的安全性有著重要的影響，近幾年很多重要安全事件（比如2008年Debian偽隨機數發生器問題導致證書公鑰易被破解、2014年Heartbleed漏洞導致伺服器私鑰洩露）都導致了大規模的證書吊銷行為。本章我們將介紹傳播證書吊銷資訊的幾種方式、它們的優缺點和現狀以及針對證書吊銷標準的若干攻擊1。

0x01 概述

---

在公鑰基礎設施體系中，CA負責簽發證書，同時，為了維護PKI的完整性，CA也負責吊銷證書。當伺服器的證書不再合法時（比如伺服器提前更換證書、證書的公鑰被破解、伺服器端儲存的證書的私鑰洩露等），負責簽發這一證書的CA必須要吊銷該證書，並透過相關途徑將該證書失效資訊告知SSL客戶端，幫助客戶端進行證書合法性校驗。CA需要維護它所簽發的所有證書的吊銷狀態。

在客戶端建立SSL連結的過程中，伺服器會向客戶端提供一個證書鏈作為SSL握手訊息的一部分，客戶端在校驗證書鏈的過程中，除了檢驗簽名等資訊的合法性外，還需要保證證書鏈中的所有證書均違背吊銷，否則連結應該被斷開。因此，在吊銷證書時，如果被吊銷的證書為葉子證書，那麼該證書理論上不能透過證書校驗；如果被吊銷的證書為CA（中間CA或根CA）證書，那麼該CA簽發的所有葉子證書都不能透過證書校驗。通常來說，每個證書都會包含如何檢查它是否被吊銷的資訊，客戶端可以根據這個資訊來檢查該證書是否已被吊銷。

目前有兩種主要的方法供客戶端查詢證書的吊銷情況：CRLs證書吊銷列表（Certificate Revocation Lists）和OCSP線上證書狀態協議（Online Certificate Status Protocol）。

0x02 詳細介紹

---

1.CRLs

CRLs是應用最廣泛的證書吊銷檢查方案。CRL通常是一個ANS.1編碼的檔案，包含了一系列元組，每個元組對應一個證書的吊銷資訊，包含吊銷證書的序列號、吊銷時間戳、吊銷原因等。CRL由CA維護，每個CA通常會維護一個或多個CRL列表，釋出它所簽發證書的吊銷狀態。同時，CRL和X.509證書類似，是有一定有效期的，因此CA會階段性重新簽發CRL，即使沒有加入新的證書吊銷資訊，95%的CA更新CRL的時間間隔在24小時之內。客戶端可以快取CRL，但是在它們過期之後還要重新下載更新了的CRL，這也是使用CRL的一個不方便之處。

幾乎所有證書都在CRL Distribution Points證書擴充套件裡放置了一個URL告訴客戶端能夠查詢它吊銷資訊的CRL所在的位置。當一個客戶端使用CRL的方式查詢證書的吊銷狀態時，它需要到證書擴充套件指定的位置下載CRL檔案，然後檢查當前證書的序列號是否在CRL的列表當中。2014年美國東北大學的一組研究人員對整個IPv4地址空間掃描得到的證書分析發現，僅4,384（0.09%）的證書不包含任何證書吊銷檢查資訊，這部分證書無法被吊銷，它們通常是一些自簽名證書。圖1是百度的SSL證書，它包含了CRL分發點資訊；圖2是12306網站的證書，它是一個自簽名證書，沒有包含CRL資訊。

圖1 百度的SSL證書CRL資訊

圖2 12306的SSL證書

2.OCSP

OCSP的應用時間比CRL稍晚，現在也已被大多數CA採用，如圖3，在2012年7月RapidSSL開始支援OCSP後，證書對OCSP技術的支援率也已經達到95%以上。OCSP最初是被設計用來解決CRLs開銷過大的問題，它允許客戶端生成一個HTTP請求來獲取證書的吊銷狀態，OCSP伺服器也被稱作OCSP應答者，由CA維護，收到請求後它們會返回一個CA簽名了的響應，包含證書的吊銷狀態（good, revoked或unknown），以及響應的有效時間，通常OCSP響應的有效時間比CRL的要長，可以快取在客戶端。OCSP查詢所需的URL被放置在Authority Information Access證書擴充套件裡。

OCSP提供了一種實時查詢證書吊銷狀態的方法，解決了很多CRL效率低下的問題，但是它依然需要客戶端向CA發出請求來確定證書是否可以被信任，向OCSP伺服器請求證書吊銷狀態的行為會將使用者的瀏覽行為資訊洩露給CA，一定程度上洩露了使用者隱私；同時，由於OCSP是實時查詢，OCSP伺服器的響應速度會影響客戶端頁面的載入速度，存在一些效能問題。總之，OCSP彌補了CRLs的一些不足，但同時也引入了一些新的問題，研究人員又提出了OCSP stapling技術來解決這些問題。

圖3 證書對CRLs和OCSP技術的支援情況

3.OCSP Stapling

OCSP Stapling是一個SSL/TLS擴充套件，X.509證書裡用status_request這個擴充套件來表明客戶端支援OCSP stapling。OCSP Stapling的工作原理是這樣的，SSL伺服器將OCSP響應快取在伺服器中，然後把它們作為SSL握手的一部分傳送給客戶端。因此，客戶端在和一個支援OCSP Stapling技術的伺服器通訊時，它可以同時接收到伺服器證書和該證書的吊銷狀態，這種機制一定程度上解決了OCSP帶來的隱私問題和效能問題。

當然OCSP Stapling也並不是完美的，它僅允許SSL伺服器快取葉子證書的OCSP響應，而不允許快取中間證書的OCSP響應，2013年一個叫做TLS Multiple Certificate Status Request Extension的TLS擴充套件被提出用來解決這個問題，但是還沒有被廣泛應用。同時，由於OCSP存在有效期，SSL伺服器也未必一直快取著OCSP響應，可能客戶端在和SSL伺服器通訊時伺服器沒有在握手訊息中插入證書吊銷狀態資訊，需要客戶端多訪問幾次才可能返回OCSP響應資訊。圖4顯示了對於所有支援OCSP Stapling技術的伺服器，客戶端發起一次請求時，僅82%的伺服器在握手訊息中插入證書吊銷資訊，而發起10次請求時幾乎所有的伺服器都會在握手訊息中插入證書吊銷訊息。

圖4 客戶端請求次數與SSL伺服器OCSP Stapling響應對應關係

0x03 吊銷檢查方案中存在的問題

---

1.客戶端支援問題

證書吊銷存在的最大問題就是客戶端對證書吊銷檢查方案的支援不充分。通常來說主流瀏覽器對SSL/TLS協議各項技術的支援比普通應用程式要好，考慮到瀏覽器可能在SSL協議建立的不同階段會使用不同的SSL庫（比如Chrome在SSL連結建立時使用Mozilla的NSS庫，而在證書校驗時依賴作業系統相關的庫），美國東北大學的研究人員做了一組實驗，將不同的作業系統與不同的瀏覽器進行組合，作業系統包括Ubuntu 14.04、Windows 8.1、OS X 10.10.2及iOS 6-8、Android4.1-5.1等，測試的瀏覽器包括Chrome、Firefox、Opera、Safari、IE等覆蓋市場所有主流瀏覽器。它們的測試發現不同瀏覽器在利用CRL和OCSP查詢證書吊銷狀態時，對於葉子證書和中間證書、普通證書和EV證書的處理情況都不相同，對於不同的OCSP伺服器響應各瀏覽器表現也不同，每種瀏覽器都存在或多或少的安全問題，桌面平臺瀏覽器在證書吊銷處理這方面的表現最好的是IE，其次是Safari以及較新版本的Opera瀏覽器，Chrome和Firefox存在的問題較多。另外，移動平臺上的所有瀏覽器都沒有進行證書吊銷狀態檢查，所以對於那些在Heartbleed漏洞中洩露了私鑰的證書，即使它們已經被吊銷，攻擊者還可以利用它們來攻擊移動平臺而不會被發現。下表為對不同瀏覽器證書吊銷狀態檢查行為的測試結果。

2.CRL效能問題

CRLs技術一直被詬病的是它的效率問題，客戶端需要將完整的CRL檔案下載下來進行證書吊銷狀態檢查。隨著越來越多安全事件的發生，大量證書被吊銷，導致CRL檔案的大小增長迅速，比如著名CA GoDaddy的吊銷資訊在2007年才158KB，到2013年已經增長到41 MB，隨著時間的推進，過大的CRL檔案將越來越不適合用來進行證書吊銷狀態檢查。

部分CA透過維護多個CRL的方式來解決CRL檔案過大的問題，每個CRL只包含所有簽發證書的子集，但即便如此，對於那些最流行的CA每個CRL的體積依然很大。下表描述了主要CA的CRL體積情況，可以看到即便GoDaddy使用了322個不同的CRL，平均每個CRL的體積依然超過1MB。

除了維護多個CRL這種方式外，有的CA還使用增量CRL的方式來解決CRL檔案過大的問題，這種技術透過讓客戶端下載最新增量 CRL，並將該 CRL 與之前的 CRL 組合在一起，以擁有已吊銷證書的完整列表。由於客戶端通常在本地快取 CRL，因此，使用增量 CRL 可潛在改進效能。要使用增量 CRL，客戶端應用程式必須瞭解並明確使用增量 CRL 來進行吊銷檢查。如果客戶端不使用增量 CRL，它會在每次重新整理其快取時從 CA 檢索 CRL，不管增量 CRL 是否存在。為此，應驗證預期應用程式是否使用增量 CRL，並進行相應的配置。如果客戶端不支援使用增量 CRL，則不應將 CRL 配置為釋出增量 CRL，或者不應將其配置為於同一間隔釋出 CRL 和增量 CRL。這仍允許未來的支援增量 CRL 的應用程式使用它們，同時可為所有應用程式提供當前 CRL。目前，使用 Windows XP 和 Windows Server 2003 家族產品中的 CryptoAPI 的所有應用程式都使用增量 CRL。由於這種技術和現行的CRL技術有一定差別，和CA維護並定時更新CRL的機制並不完全相容，出微軟的產品外別的應用程式使用這種技術的還不多見。

0x04 參考資料

1. Liu Y, Tome W, Zhang L, et al. An End-to-End Measurement of Certificate Revocation in the Web's PKI[C]//Proceedings of the 2015 ACM Conference on Internet Measurement Conference. ACM, 2015: 183-196.
2. Zhang L, Choffnes D, Levin D, et al. Analysis of SSL certificate reissues and revocations in the wake of Heartbleed[C]//Proceedings of the 2014 Conference on Internet Measurement Conference. ACM, 2014: 489-502.
3. https://msdn.microsoft.com/zh-cn/library/cc782162(v=ws.10).aspx