我們很高興 Squarespace 決定使用 HTTPS 保護他們託管的數百萬個網站！在與他們的團隊交談時，我們了解到他們從一開始就部署了 OCSP Stapling，我們對此印象深刻。我們請他們在我們第一篇客座部落格文章中與我們的讀者分享他們的經驗（希望未來會有更多文章）。

- Josh Aas，執行董事，ISRG / Let’s Encrypt

OCSP Stapling 是一種用於檢查憑證撤銷狀態的線上憑證狀態協定 (OCSP) 的替代方法。它允許憑證的提供者承擔提供 OCSP 回應的資源成本，方法是將由 CA 簽署的時間戳記 OCSP 回應附加（「釘選」）到初始 TLS 握手，從而消除用戶端聯絡 CA 的需要。憑證持有者會定期查詢 OCSP 回應者並快取回應。

傳統的 OCSP 要求 CA 為每個請求憑證撤銷資訊的用戶端提供回應。當為熱門網站發出憑證時，大量查詢會開始湧入 CA 的 OCSP 回應者伺服器。這會構成隱私風險，因為資訊必須經過第三方，而且第三方能夠判斷誰在何時瀏覽了哪個網站。它也可能產生效能問題，因為大多數瀏覽器會在網頁上載入任何內容之前聯絡 OCSP 回應者。OCSP Stapling 是有效率的，因為使用者不必與 CA 建立單獨的連線，而且它是安全的，因為 OCSP 回應是經過數位簽署的，因此不會在未被偵測到的情況下遭到修改。

Squarespace 的 OCSP Stapling

當我們規劃在 Squarespace 平台上為所有自訂網域推出 SSL 時，我們決定在推出時支援 OCSP Stapling。由我們的 邊緣基礎設施團隊建置的反向代理負責終止所有 SSL 流量，它以 Java 編寫，並由 Netty 提供支援。不幸的是，Java JDK 8 僅具有初步的、僅限用戶端的 OCSP Stapling 支援。JDK 9 引入了帶有 JEP 249 的 OCSP Stapling，但它尚未可用。

我們的反向代理不使用 JDK 的 SSL 實作。相反地，我們透過 netty-tcnative 使用 OpenSSL。目前，原始的 tcnative 和 Netty 的 fork 都不支援 OCSP Stapling。然而，tcnative 函式庫公開了 OpenSSL 的內部運作，包括 SSL 內容和引擎的位址指標。我們能夠使用 JNI 來擴充 netty-tcnative 函式庫，並使用 tlsext_status OpenSSL C 函數來新增 OCSP Stapling 支援。我們的擴充功能是一個獨立的函式庫，但我們也可以將它摺疊到 netty-tcnative 函式庫本身中。如果有興趣，我們可以在 Netty 的下一個 API 中斷開發週期中將其作為上游貢獻。

我們初始 OCSP Stapling 實作的目標之一是最大程度地減輕 OCSP 回應者（在本例中為 Let's Encrypt）運營商的負擔。由於我們平台上網站流量的性質，我們有非常長的尾部。至少從一開始，我們不會預先擷取並快取所有 OCSP 回應。我們決定非同步擷取 OCSP 回應，並且我們嘗試僅在未來可預見的時間內有多個用戶端將使用它時才這樣做。Bloom 篩選器用於識別不值得快取的「一次性奇蹟」。

Squarespace 投資於我們客戶網站及其訪客的安全性。我們將繼續改進我們的 OCSP Stapling 實作，最終讓所有請求都具有 OCSP 釘選。如需更深入討論傳統 OCSP 的安全挑戰，我們建議您閱讀這篇部落格文章。