數位憑證一旦被撤銷，瀏覽器必須即時得知。OCSP（線上憑證狀態協定）正是為此而生，但它在設計上埋下了隱私洩漏與安全缺陷的地雷。
OCSP 如何運作：即時查詢取代批次下載
傳統 CRL（憑證撤銷清單）採批次下載，檔案龐大且更新延遲。OCSP 改為單張查詢模式：瀏覽器建立 HTTPS 連線時，擷取伺服器憑證的序號（Serial Number），向 CA 指定的 OCSP Responder 發送 HTTP 請求，Responder 簽名後回傳三種狀態之一：
- Good：憑證有效，連線繼續
- Revoked：憑證已撤銷，瀏覽器應中斷連線
- Unknown：Responder 無此憑證記錄
查詢內容依 RFC 6960 規範，封裝為 ASN.1 格式，透過 HTTP GET 或 POST 傳輸。整個流程在 TLS 握手期間同步發生，每次連線都觸發一次對外查詢。
兩大核心缺陷：隱私洩漏與 Soft Fail
第一個缺陷是隱私洩漏。每次查詢都將使用者造訪的網站域名（透過憑證序號可反查）回報給 CA，CA 因此能建構完整的用戶瀏覽記錄。這意味著 CA 實際上扮演了全球規模的流量監控者角色，違背 HTTPS 保護隱私的初衷。
第二個缺陷是 Soft Fail（軟性失敗）機制。當 OCSP Responder 無法連線時，大多數瀏覽器選擇「靜默放行」而非阻擋連線。攻擊者只需對 OCSP 伺服器發動 DoS 攻擊或封鎖網路請求，即可讓已撤銷的憑證繼續被信任，撤銷機制形同虛設。Hard Fail（強制失敗）雖更安全，但會因 OCSP 服務中斷導致大規模連線失敗，實際部署幾乎不採用。
💡 重點整理
- OCSP 向 CA 的 Responder 查詢憑證序號，回傳 Good／Revoked／Unknown。
- 每次 TLS 握手觸發查詢，CA 可藉此追蹤用戶瀏覽行為。
- Soft Fail 設計讓 DoS 攻擊可繞過撤銷檢查，是關鍵安全漏洞。
- 業界以 OCSP Stapling 緩解隱私問題，由伺服器預先取得回應並附加於握手中。
OCSP 在即時性上超越 CRL，卻在隱私與可靠性上留下難以忽視的設計缺陷。理解這些限制，是評估 PKI 安全架構時不可跳過的一環。
留言
張貼留言