HTTPS證書吊銷機制已壞，是時候需要一些新工具了！

作者簡介：Scott Helme是一名安全研究人員和國際演說家。他還是securityheaders.io和report-uri.io的創始人，這些免費工具可幫助企業更好地部署安全機制。

Certificate Transparency和OCSP Must-Staple未能足夠快地落實起來。

這篇文章最初發表在Scott Helme的個人博客上。

眼下我們在互聯網上有個小問題，但我覺得這會逐漸成為更嚴重的問題：越來越多的網站在獲得證書（部署HTTPS所需的至關重要的文件），但是一旦證書方面出了岔子，我們無法保護自己。

證書

隨著越來越多的網站部署HTTPS，我們目前看到互聯網證書迎來了一股熱潮。除了HTTPS在安全和隱私方面明顯具有優勢外，還有好多原因促使你想要考慮改用這種安全的連接協議，我在文章《仍認為你不需要HTTPS？》（https://scotthelme.co.uk/still-think-you-dont-need-https/）中概述了這些原因。這種安全證書通常被稱為「SSL證書」或「HTTPS證書」，更廣泛的互聯網用戶正以我們之前在互聯網發展史上從未見過的速度獲得它們。我每天搜索前100萬個網站，分析其安全性的方方面面，每6個月就發布一份報告。你可以在這裡（https://scotthelme.co.uk/tag/crawl/）查看報告，不過眼下關注的主要結果是HTTPS的採用。

前100萬個網站中使用HTTPS的百分比

我們不僅在繼續部署HTTPS，部署的速度也在加快。這才是真正取得的進展。獲得證書的過程逐漸變得越來越簡單，現在歸功於出色的Let s Encrypt，還能免費獲得證書。簡而言之，我們向證書管理機構（CA）發送證書籤名請求（CSR），CA會質詢我們，證明我們是該域的所有者。這常常通過設置DNS TXT記錄或將質詢碼託管在我們域的隨機路徑上的某個地方來完成。一旦成功通過這個質詢，CA會頒發證書，然後我們可以將它出示給訪客的瀏覽器，在地址欄中獲得綠色掛鎖和「HTTPS」。

獲得證書的過程

我寫了幾個教程幫助大家了解這個過程，包括如何入手、如何設置智能更新機制以及如何使用雙證書。所以這很好。有什麼問題嗎？

問題在於，如果證書方面出了岔子，你就要遭殃了。

「我們已經被黑！

根本沒人想聽到這句話，但殘酷的現實是，我們確實聽到，而且司空見慣。一旦黑客能訪問我們的伺服器，就可以找許多目標下手，他們能訪問的對象之一常常就是我們的私鑰。我們用於HTTPS的證書是公共文檔――我們將它們發送給連接到我們網站的任何人，但如果使用我們證書的其他人沒有我們的私鑰，就訪問不了。瀏覽器與網站建立一條安全連接後，會檢查伺服器擁有它所要使用的那個證書的私鑰，這就是為什麼只有我們才能使用自己的證書，別人用不了。不過，要是攻擊者得到了我們的私鑰，情況不一樣了。

伺服器泄密後，我們的私鑰落到攻擊者的手裡

鑒於攻擊者已設法獲得了我們的私鑰，他們可以使用我們的證書證明他們就是我們。再說一遍：如果你的鑰匙失竊，那意味著別人在互聯網上可以證明他們就是你。這個問題很嚴重；在你認為「這永遠不會發生在我身上」之前，應該記得Heartbleed。OpenSSL庫中的這個小漏洞讓攻擊者得以竊取私鑰，就算你根本沒有做錯什麼，它照樣到處肆虐。除此之外，私鑰還會以無數的方式因意外或疏忽而泄露。一個簡單的事實是，我們可能丟失私鑰；若出現這種情況，我們需要有法子來阻止攻擊者使用我們的證書。我們需要吊銷證書。

吊銷證書

萬一中招，我們吊銷證書，那樣攻擊者無法濫用證書。一旦證書被標記為「已吊銷」，Web瀏覽器就知道不信任該證書，哪怕證書是有效的。所有者要求吊銷證書後，客戶不應該接受該證書。

請求吊銷證書

一旦我們知道自己已中招，要聯繫CA，要求對方吊銷我們的證書。我們要證明自己是該證書的所有者；一旦我們證明了這點，CA將把該證書標記為已吊銷。由於證書已被吊銷，我們需要一種方法將該吊銷信息通知給可能需要該信息的任何客戶。吊銷後，訪客的瀏覽器並不立即知道――當然，這是個問題。我們可以使用兩種機制來提供該信息：證書吊銷列表（CRL）或在線證書狀態協議（OCSP）。

證書吊銷列表

CRL其實是個很簡單的概念，它就是一份列表，列出了CA標記為已吊銷的所有證書。客戶可以聯繫CRL伺服器，下載一份列表。有了這份列表，瀏覽器可以檢查：向它出示的證書是否在該列表中。如果證書在列表中，瀏覽器現在知道證書是壞的，不該信任它。瀏覽器應該會彈出錯誤信息，放棄連接。如果證書不在列表中，那麼一切都很好，瀏覽器可以繼續連接。

下載CRL

CRL的問題在於，它們含有來自負責維護的某個CA的許多吊銷證書。因不了解太多細節，它們被CA擁有的每個中間證書搞壞，CA可能將列表分解更小的塊。不管列表如何分解，我想要表明的意思仍然一樣：CRL通常很龐大。另一個問題是，如果客戶沒有一份新的CRL，必須在最初連接到你網站時獲取一份，這可能會讓你網站載入看起來比實際上慢得多。

這聽起來不是特別好，那我們不妨來看看OCSP如何？

在線證書狀態協議

OCSP提供了一種好得多的辦法來解決該問題，與CRL方法相比具有顯著優勢。使用OCSP，我們向CA詢問某一個證書的狀態。這意味著CA要做的就是回應證書是好的/已吊銷的答案，這比CRL小得多。不賴！

獲取OCSP響應

沒錯，OCSP在性能方面比獲取CRL具有顯著優勢，但是這個性能優勢有其代價。這也是相當大的代價：你的隱私。

如果我們考慮一下OCSP請求的是什麼（請求一個非常特殊的證書的狀態），你可能會開始意識到泄漏了一些信息。如果你發送OCSP請求，基本上是向CA問這個：

「pornhub.com的證書是否有效？」

所以，這根本不是一種理想的場景。現在你將自己的瀏覽記錄內容通告給了你甚至一無所知的某個第三方，這完全以HTTPS的名義――而HTTPS原本旨在為我們加強安全和隱私。這是不是頗具諷刺意味？

硬失效

不過等等：還有別的方面。我在上面談論了CRL和OCSP響應，這是瀏覽器可以用來檢查證書是否被吊銷的兩種機制。它們看起來就像這樣。

CRL和OCSP檢查

瀏覽器一收到證書，就會聯繫這其中一個服務，並執行必要的查詢，最終確定證書的狀態。但是如果你的CA遭遇不幸、基礎設施宕機，將會怎樣？如果看起來像下面這種情況，將會怎樣？

CRL和OCSP伺服器宕機

這時候，瀏覽器只有兩個選擇。它可以拒絕接受證書，因為它無法檢查吊銷狀態，或者在不知道吊銷狀態的情況下冒險接受證書。這兩個選擇各有優缺點。如果瀏覽器拒絕接受證書，那麼每當你的CA遭遇不幸、基礎設施又宕機，你的網站也會跟著宕機。如果瀏覽器繼續接受證書，那麼它就面臨使用可能被盜的證書這個風險，因而將用戶暴露於相關風險。

這是個艱難的選擇――不過現在，這任何一種情況沒有實際發生。

軟失效

如今實際發生的是，瀏覽器會做我們所說的「軟失效吊銷檢查」（soft fail revocation check）。也就是說，瀏覽器會試著檢查證書吊銷，但是如果響應沒有返回，或者沒有在短時間內返回，瀏覽器會完全不理。更糟糕的是，Chrome甚至根本不執行吊銷檢查。

是的，你沒有看錯，Chrome甚至不試著檢查它遇到的證書的吊銷狀態。你可能覺得更奇怪的是，我完全認同Chrome的做法；我很高興地說，Firefox看起來很快也會加入這個行列。

不妨聽我細細道來。我們在硬失效方面遇到的問題很明顯：如果CA遭殃，我們也跟著遭殃。這就是為何我們提到了軟失效。瀏覽器現在試著執行吊銷檢查，但如果花太長時間，或者CA似乎宕機，它最終會放棄檢查。

等等，如果「CA似乎宕機？」，就會放棄吊銷檢查。我在想攻擊者會不會模仿這個？

攻擊者阻止吊銷檢查

如果攻擊者對你執行中間人攻擊（MITM），他們只要阻止吊銷請求，讓人覺得好像CA宕機。然後瀏覽器會對檢查進行軟失效處理，繼續開心地使用已吊銷的證書。每當你瀏覽並遇到該證書，又沒有受到攻擊，你都要承受這筆開銷：執行吊銷檢查，查明證書沒有被吊銷。

谷歌的亞當·蘭利（Adam Langley）對吊銷性質作了最生動的描述：它好比是安全帶，車輛碰撞後迅速發揮保護作用。他說的沒錯。你每天鑽進汽車，繫上安全帶，讓你覺得貌似很安全。後來有一天，出現了狀況――你撞車了，從擋風玻璃鑽了出來。就在你需要它的時候，它卻讓你失望。

解決問題

眼下，沒有一種可靠的方法來解決這個問題。吊銷機制是壞的。不過有幾種機制值得一提，將來我們會有一種可靠的吊銷檢查機制。

專有機制

如果網站中招，攻擊者拿到了私鑰，他們會冒充該網站，大搞破壞。這可不妙，但結果可能更糟。如果CA中招，攻擊者獲取了中間證書的簽名私鑰，會怎樣？這將是一場災難，因為攻擊者隨後只要給自己的證書籤名，就可以冒充他們想要冒充的任何網站。Chrome和Firefox都有各自的機制（其工作原理一樣），而不是對中間證書的吊銷執行在線檢查。

CRLsets和OneCRL

Chrome將其機制稱為CRLsets，Firefox將其機制稱為OneCRL，它們通過合并可用的CRL，從中選擇需要加入的證書來管理吊銷證書列表。所以，我們包括了像中間證書這樣的高價值證書。

OCSP Must-Staple

為了解釋「OCSP Must-Staple」是什麼，我們先需要大致介紹OCSP封套（OCSP stapling）的背景。我不會作太多的介紹，可以去我的博客了解OCST封套（https://scotthelme.co.uk/ocsp-stapling-speeding-up-ssl/），不過核心內容是：OCSP封套提供了OCSP響應以及證書，讓瀏覽器沒必要執行OCSP請求。它之所以被稱為「OCSP封套」，是由於其想法是，伺服器會「封套」OCSP對證書的響應，並將兩者一併提供。

OCSP封套的實際運作

乍一看，這似乎有點奇怪，因為伺服器幾乎將其自己的證書「自我認證」為未吊銷，但它都能檢查出來。OCSP響應僅在短時間內有效，由CA簽名，簽名方式與簽名證書的方式一樣。因此，正如瀏覽器可以驗證證書絕對來自CA，它也可以驗證OCSP響應來自CA。這解決了OCSP重大的隱私問題，還消除了客戶要執行這個外部請求的負擔。完勝！

不好意思，但實際上並不那麼好。OCSP封套是很好，我們在自己的網站上都應該支持它，但是坦率地說我們認為攻擊者會啟用OCSP封套嗎？不，他們當然不會。我們需要一種方法迫使伺服器進行OCSP封套，這就是OCSP Must-Staple的用途。我們向CA請求證書時，要求對方在證書中設置OCSP Must-Staple標誌。這個標誌告訴瀏覽器：證書在提供時必須附有OCSP封套，否則將被拒絕。設置標誌很容易。

CSR中的OCSP must-staple

鑒於我們有了該標誌已設置的證書，我們（主機）必須確保我們採用OCSP封套，否則瀏覽器不接受我們的證書。萬一中招、攻擊者獲得我們的密鑰，他們在使用我們的證書時還要提供OCSP封套。如果他們不附上OCSP封套，瀏覽器將拒絕證書。如果他們果真附有OCSP封套，那麼OCSP響應會說證書已吊銷，瀏覽器將拒絕。哇哦！

攻擊者企圖使用must-staple證書

OCSP Expect-Staple

雖然Must-Staple聽起來是解決吊銷問題的好辦法，它其實還沒有到位。我發現最大的問題之一是，作為網站運營者，我實際上不知道OCSP封套有多可靠、客戶對封套的響應又是否滿意。要是未啟用OCSP Must-Staple，這其實不是個問題，但如果我們果真啟用OCSP Must-Staple，然後又沒有適當地或可靠地使用OCSP封套，我們的網站會開始出問題。

為了獲得關於我們在OCSP封套方面怎麼做的一些反饋，可以啟用一項名為OCSP Expect-Staple的功能。之前這方面我寫過一篇文章，可以在博客OCSP Expect-Staple（https://scotthelme.co.uk/ocsp-expect-staple/）中了解所有細節，不過這裡將給出簡短版本。你可以請求添加HSTS preload列表：如果對OCSP封套不滿意，讓瀏覽器向你發送報告。可以自行收集報告，或使用我的服務report-uri.io替你收集。如果你啟用了OCSP Must-Staple，就能了解遇到問題的頻次到底如何。

由於添加HSTS preload列表不如我希望的那麼簡單，我還寫了一個規範，定義一個新的名為「Expect-Staple」的安全報頭，以提供同樣的功能，但減少了工作量。現在你可以在啟用Must-Staple之前，設置該報頭，並啟用報告機制、以獲得我們迫切需要的反饋。啟用報頭很簡單，就像啟用其他所有安全報頭那樣：

未授權證書

我們在探討吊銷話題時要考慮的另一個方面是未授權證書（rogue certificate）。要是有人設法危及CA或以其他方式獲得不該擁有的證書，我們該如何知道這個情況？

如果我現在攻入了CA，獲得了你網站的證書，又沒有告訴你，除非此事被廣泛報道，否則你蒙在鼓裡。你可能甚至面臨內部威脅，貴企業中某個人可能不用走適當的內部渠道就能獲得證書，可以隨意處理證書。我們需要有辦法確保透明度達到100%，我們很快會如願以償，這歸功於名為Certificate Transparency的開放框架。

Certificate Transparency

Certificate Transparency是一個新的要求，明年初起將是強制性要求，將要求所有證書都記錄在公共日誌中，如果瀏覽器要信任它們的話。你可以閱讀該文，了解Certificate Transparency的更多詳細信息，但通常發生的情況是，CA會將它頒發的所有證書記錄在Certificate Transparency日誌中。

Certificate Transparency日誌

這種日誌是完全公開的，任何人都能搜索它們，所以其想法是，如果證書是頒發給你網站的，你會了解相關情況。比如在這裡（https://crt.sh/?q=scotthelme.co.uk），你可以看到為我域頒發的所有證書，您還可以搜索自己的證書。還可以使用SSLMate的CertSpotter來搜索證書。此外，我使用Facebook Certificate Transparency Monitoring工具，每當為你域分發了新的證書，該工具會發電子郵件通知你。

Certificate Transparency是個很棒的想法，我迫不及待地希望它成為強制性要求，但它只是第一步。了解這些證書雖好，但吊銷證書方面仍存在所有上述問題。話雖如此，我們每次只能解決一個問題；如果我們不知道需要吊銷的證書，世界上再好的吊銷機制也無濟於事。Certificate Transparency至少在這方面給了我們許多。

Certificate Authority Authorization

阻止證書頒發比試圖吊銷證書要容易得多，這正是Certificate Authority Authorization（證書管理機構授權）讓我們開始做的事情。簡單來說，我們現在可以授權只有特定的CA為我們頒發證書，而不像現在我們根本無法表明任何偏好。就像創建DNS記錄一樣簡單：

雖然CAA不是一種特彆強大的機制，它在誤頒發的情況下無助於事，但是在一些情況下它能幫助我們，我們可以通過創建CAA記錄來表明我們的偏好。

結束語

目前有個真正的問題：如果有人獲得了我們的私鑰，我們無法吊銷證書。想像一下，要是下一個Heartbleed出現，那會是怎樣的場面？為了限制破壞所造成的影響，你能做的事情之一是，縮短你獲得的證書的有效期。改用一年或更短，而不是三年。Let s Encrypt只頒發有效期只有短短90天的證書！如果證書的生命周期縮短，即使你中了招，問題也不大，因為攻擊者在證書過期之前濫用證書的時間較短。除此之外，我們幾乎無計可施。

為了證明這種軟失效檢查毫無意義，你可以為ocsp.int-x3.letsencrypt.org添加一個hosts條目，以便解析至127.0.0.1，或者通過其他方法來阻止它，然後再試一下。這回，頁面會順利載入，因為吊銷檢查將失效，瀏覽器會繼續載入頁面。

最後我想要說的是這個問題：我們應該修復吊銷機制嗎？改天再聊這個話題！

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！