圖1 百度的SSL證書CRL信息
在前面的章節我們討論了部分SSL/TLS握手協議、記錄協議中存在的安全問題，針對它們的攻擊以及相應的加固方案。在SSL/TLS所依賴的PKI體系中，證書吊銷過程同樣對SSL通信的安全性有著重要的影響，近幾年很多重要安全事件（比如2008年Debian偽隨機數發生器問題導致證書公鑰易被破解、2014年Heartbleed漏洞導致服務器私鑰泄露）都導致了大規模的證書吊銷行為。本章我們將介紹傳播證書吊銷信息的幾種方式、它們的優缺點和現狀以及針對證書吊銷標準的若干攻擊1。
在公鑰基礎設施體系中，CA負責簽發證書，同時，為了維護PKI的完整性，CA也負責吊銷證書。當服務器的證書不再合法時（比如服務器提前更換證書、證書的公鑰被破解、服務器端存儲的證書的私鑰泄露等），負責簽發這一證書的CA必須要吊銷該證書，并通過相關途徑將該證書失效信息告知SSL客戶端，幫助客戶端進行證書合法性校驗。CA需要維護它所簽發的所有證書的吊銷狀態。
在客戶端建立SSL鏈接的過程中，服務器會向客戶端提供一個證書鏈作為SSL握手消息的一部分，客戶端在校驗證書鏈的過程中，除了檢驗簽名等信息的合法性外，還需要保證證書鏈中的所有證書均違背吊銷，否則鏈接應該被斷開。因此，在吊銷證書時，如果被吊銷的證書為葉子證書，那么該證書理論上不能通過證書校驗；如果被吊銷的證書為CA（中間CA或根CA）證書，那么該CA簽發的所有葉子證書都不能通過證書校驗。通常來說，每個證書都會包含如何檢查它是否被吊銷的信息，客戶端可以根據這個信息來檢查該證書是否已被吊銷。
目前有兩種主要的方法供客戶端查詢證書的吊銷情況：CRLs證書吊銷列表（Certificate Revocation Lists）和OCSP在線證書狀態協議（Online Certificate Status Protocol）。
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證書
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技術的支持情況
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響應對應關系
證書吊銷存在的最大問題就是客戶端對證書吊銷檢查方案的支持不充分。通常來說主流瀏覽器對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漏洞中泄露了私鑰的證書，即使它們已經被吊銷，攻擊者還可以利用它們來攻擊移動平臺而不會被發現。下表為對不同瀏覽器證書吊銷狀態檢查行為的測試結果。
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的機制并不完全兼容，出微軟的產品外別的應用程序使用這種技術的還不多見。