數位憑證一旦被撤銷，瀏覽器必須即時得知。 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 安全架構時不可跳過...