我们很高兴 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 的分支都没有 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 响应，并且我们尝试只在多个客户端将在可预见的未来使用它时才执行此操作。布隆过滤器用于识别不值得缓存的“一次性奇迹”。

Squarespace 投资于客户网站及其访问者的安全性。我们将继续改进我们的 OCSP Stapling 实现，最终在所有请求中都包含 OCSP 钉住。有关传统 OCSP 安全挑战的更深入讨论，我们推荐 这篇文章.