2016年1月10日 星期日

OCSP & CRL 介紹

這篇主要是要談論在 PKI 架構下，如何查詢一張 X.509 憑證 ( Certificate ) 的有效性？
舉例：
  • 瀏覽器 (Browser) 如何驗證支援 SSL 連線的伺服器所使用的憑證 Certificate 是有效的。
  • 自行開發的應用程式，如何透過程式碼來查詢某張憑證是否已經被 CA 單位所撤銷 (Revoke)。
首先，我們先定義"有效的憑證"：
  • 該憑證是經由公認的 CA 或是執行的系統所信任的 CA 發行的憑證。
  • 憑證的是否在有效期間內。
  • 該憑證沒有被發行憑證的 CA 所撤銷 ( Revoked )。
我們會分別以下面的主題來解釋 OCSP 和 CRL 這兩個在 PKI 架構的規範。 
  • 基本概念介紹
  • 實務上的應用
  • 優點缺點

CRL 基本概念介紹

CRL 是 Certificate Revocation List 的縮寫，顧名思義就是紀錄被CA所撤銷的憑證清單。 實際上他是一個發行憑證的 CA 用來對外公告，這個 CA 所發行的憑證，雖然憑證上的日期仍然是有效的，但有這些憑證當中，哪些是因為某些因素而被撤銷的憑證。被憑證撤銷的理由 (Reason) 很多，RFC 的規格上定義了幾個常見的理由 如下：
  • unspecified (0)
  • keyCompromise (1)
  • CACompromise (2)
  • affiliationChanged (3)
  • superseded (4)
  • cessationOfOperation (5)
  • certificateHold (6)
  • removeFromCRL (8)
  • privilegeWithdrawn (9)
  • AACompromise (10)

實際上，CRL 就是一個檔案，任何人都可以根據憑證中所指定的URI位置取得這份檔案。如果你透過工具來檢視憑證，我們可透過 OpenSSL 指令來檢視憑證內容

shell>openssl x509 -in cert.crt -text

如果發出這張憑證單位的 CA 有提供 CRL 資訊，你可以在 X.509 的 V3 Extension 找到一個
"X509v3 CRL Distribution Points" 的資訊，它會顯示一個或是一個以上的 URI，如下圖紅色標示的部分：
當你將那段URI的位置，透過工具如 wget or curl 或是瀏覽器來取得這個 CRL 檔案時，檔案的內容就可能紀錄著類似藍色箭頭所指示的內容，裡面會包含哪些憑證已經在何時被撤銷。每張憑證都具有一個 Serial Number, 他就像是憑證的身分證號碼，由發行的CA單位所管理，這些 Serial Number 必須是在這個CA單位中是唯一。然而，CRL 的檔案通常都是用DER或是PEM的編碼過的，所以你無法用一般的編輯器直接來檢視他的內容。此外，它會包含CA所簽署的簽章(Signature)資訊，如此才能證明這個CRL檔案是由 CA 單位所公告的資訊。我們可透過 OpenSSL 指令來檢視一個CRL檔案的內容

shell>openssl crl -in crl.der -text -noout

 你就可以看到，類似下圖所示的內容：


此外，你可以在最下方看見一個簽章的資訊，例如下圖：

它說明了這個 CRL 檔案是由 sha256withRSAEncryption 的演算法所簽署的簽章 (Signature)，因此取得這個CRL的檔案後，要拿它來判斷是否有憑證被撤銷之前，應該要驗證這個 CRL 檔案的簽章，以確保這個CRL檔案是沒有被竄改過的。那要如何驗證呢？這時要檢視 CRL extension 中的 Authority Key Identifier。這表示這個簽章要使用 Authority Key Identifier 所指定的 Public Key 來驗證。如果發行憑證的 CA 沒有特別針對 CRL 而另外指定用於 signing CRL 專屬的 certificate 時，這個 Authority Key Identifier 通常就是發行 CA 的 public key id。因此你就可以透過 CA certificate 來驗證這個CRL的簽章是否正確。

CRL extensions:
   X509v3 Authority Key Identifier: 
   keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B

實務上的應用

一般來說，程式(例如: Browser 或自行開發會使用到憑證的應用程式)會根據憑證在 X.509 的 V3 Extension 找到一個"X509v3 CRL Distribution Points" 的資訊去取得這份 CRL 檔案。然而，CRL 檔案通常是由 CA 單位來定期發佈, 而 CRL的檔案中會記錄著這份CRL的有效期間，以及下次更新的時間。因此，要使用CRL 的應用程式，可以根據 CRL 的有效期間來決定是否重新取得這份CRL檔案，或是只接使用在本地端的 CRL 檔案即可。

CRL的優點

  • CA 實作CRL是相對容易的，只需要定期將被撤銷的憑證資訊更新到 CRL 之中即可。
  • CRL 取得容易，一般來說，需要 CRL 的應用程式可以直接透過 HTTP 就取得這個檔案。

CRL的缺點

  • CRL 檔案的內容可能非常大，如果 CA 單位長時間下來撤銷許多發行的憑證時，這個 CRL 檔案內容就會非常的大，可能高達25MB以上。有興趣的讀者可以參考這篇Digging Into Certificate Revocation Listsj文章。
  • CRL 檔案資訊不夠即時，可能造成安全上的空窗期。因為CRL檔案是每隔一段時間才公布，因此在下次公布CRL檔案之前，有憑證被撤銷時，要等到下次公布才能得到這個資訊。
  • 如果程式無法下載 CRL 檔案，則應用程式可能會直接信任它想要確認的憑證。

Base CRL 和 Delta CRL

由於，CRL 本身在設計上有這樣的缺點，因此後來提出另一個的解決方式稱為 Delta CRL。
Delta CRL 是指記錄部分的被撤銷的憑證資訊，而不是全部的被撤銷的憑證資訊。並且縮短了 Delta CRL 的發佈時間。舉例，原本的 CRL 發佈時間是 10 天發佈 1 次，而這個 CRL 又被稱為 Base CRL。而 Delta CRL 的發佈週期就比較短一點，可能只要 2 天就發佈一次。因此，Delta CRL 只會記錄在這 2 天內有被撤銷的憑證資訊，並且在 Delta CRL 檔案中會記錄著他的 Base CRL 是哪一個版號。而應用程式只要每2天重新抓取這個 Delta CRL檔案，加上原本的 Base CRL檔案 就可以得到完整的 CRL 資訊。

請參考下方這張圖，Base CRL 檔案中會記錄著一個 X509v3 Freshest CRL的資訊，而上面所記錄的 URI位置就是 Delta CRL檔案的位置。當你下載這個 Deltra CRL檔案後，即可發現 Delta CRL 檔案結構和 Base CRL一樣，只是 X509v3 Delta CRL Indicator 標記這個 CRL 檔案是一個 Delta CRL 檔案，此外，它記錄著是根據哪一個 Base CRL的版號，當作比對的基礎，而產生這份 Delta CRL。

OCSP

基本概念介紹

OCSP 是 Online Certificate Status Protocol 的縮寫，它目的在於提供線上動態查詢憑證的狀態。OCSP 本身提供了應用程式更多的彈性，來根據使用上的需要來查詢憑證的狀態。簡單的說就是應用程式能夠根據憑證的序號，發出OCSP請求到憑證上所記錄的 OCSP  URI 來查詢憑證的狀態。我們可以參考下面這張概念圖：

由上圖，可以看到左右兩邊橘色部分是有關數位簽章的資訊，右邊是 OCSP 的 Response 的格式示意圖，而橘色的部分是指這個 OCSP Response 內容的簽章。接收端應該要驗證這個簽章無誤後，才能夠信任這個 OCSP 的回應內容。而左邊，是發出 OCSP 請求的客戶端把請求的內容也算出了一個簽章資訊。但，並不是強制性的，這完全是根據實作 OCSP responder來決定是否要強制要求，發出 OCSP 請求的客戶端一定要產生這個簽章。

當客戶端發出請求給 OCSP Responder時候，這時可以根據憑證的狀態有3種回答 ：

  • Good - 表示憑證的狀態是在有效期內，而且沒有被撤銷
  • Revoked - 表示憑證已經被撤銷
  • Unknown - 表示 OCSP Responder 無法認得這張憑證

實務上的應用

實務上就是大部份知名的瀏覽器都支援 OCSP 的實作，來驗證瀏覽的網頁伺服器所使用的HTTPS的憑證是否有效。瀏覽器連上某個網站時候，它會根據伺服器所使用的憑證內容所記錄的 OCSP Responder 位置，發出 OCSP 請求去詢問這張憑證目前的狀態，來決定是否信任這個網站。

OCSP 優點

  • 應用程式可以一次只問一張憑證的狀態即可，不需要像 CRL 把所有的撤銷的憑證資訊都下載下來。
  • 降低了發佈的時間延遲，縮短了這方面的問題。

OCSP 缺點

  • 對 OCSP Responder 的流量會相當大
  • 如果遇到不支援 OCSP 的客戶端或是連不到 OCSP Responder的情形，會造成客戶端直接信任伺服器憑證的狀況，那就會讓駭客能夠偽裝成伺服器來進行攻擊

OCSP Stapling

由於 OCSP 原本的設計方式是，會由一個 OCSP Responder 來負責回答客戶端的 OCSP 請求。然而在實務上瀏覽器為了避免要發兩次請求到不同的位置，而造成延遲，另一方面也是為了減輕 OCSP Responder的負擔，讓瀏覽器不需要每次都到 OCSP Responder來詢問。因此，發展出了另一個改良版本的做法，稱作 OCSP Stapling。它是指由伺服器端同時提供 OCSP 回應的做法。這樣瀏覽器連接到這個網站時，就不需要再發另一個請求到另一個位置的 OCSP Responder，可以在同一個連線當中就可以得到這張伺服器所使用的憑證是否還是有效。
當然，要支援 OCSP Stapling 是需要付出代價的，那就是你所架設的伺服器必須要能夠支援。目前常見的網頁伺服器都有支援，如：Windows, Apache, Nginx 等等。

Reference 




張貼者： 於
標籤： , , , , , , ,

3 則留言:

歡迎留言討論與指教

訂閱： 張貼留言 (Atom)