OCSP 隐私：响应方看到的是证书，而不是你的 URL

一次状态检查只就一张证书提一个问题，而回答走它自己的连接。它不包含导致这次检查的页面路径。隐私讨论常把这次交换当作浏览历史的信息流，这既高估了请求携带的内容，也低估了响应方能观察到的内容。先读懂请求，再判断它揭示了什么。

请求标识的是一张证书

OCSP 证书标识符由哈希函数、两个颁发者哈希和目标证书的序列号构成，RFC 6960 对此有规定。每个字段都指向一张证书，而不是 URL 或 HTTP 请求。

页面路径、查询字符串和任何表单内容都不在标准标识符中。若声称响应方收到了确切的 URL，就需要来自证书检查之外的证据。请求仍然指明一张证书和一个时刻，响应方也可能知道是哪个服务在呈现它。

缺失的是页面，而不是整个上下文。证书检查加上已知服务再加上重复出现的来源，可能比其中任何一项单独来看都更有信息量。

响应方看到抵达它的连接：源地址、时间，以及其部署所记录的任何传输元数据。如果状态请求走 VPN，那个来源可能是 VPN 出口，而不是用户的接入网络。不要因为两者属于同一个浏览器会话，就假定状态请求与页面请求走同一条路径。

检查客户端支持的路由与验证行为，而不是从单条追踪记录去推断。拆分隧道可能把两个请求送往不同方向。

装订响应是另一种常见模式。RFC 6066 的 TLS status_request 扩展允许服务器把 OCSP 响应附在自己的握手中，因此客户端验证的是被交给它的内容，而不是自己为该连接去取状态。这一转变改变了观察者。取回由服务器一侧完成，客户端自己的地址在那条连接上永远不会到达响应方。

这些都不能保证客户端永远不会再发起另一次验证请求。链的构建、状态策略和受支持的机制都因实现而异。

一个浏览器里的证书查看器并不是对每个操作系统和 VPN 客户端的描述。同一份网络抓包在不同的验证设置下可能意味着不同的事情。

缓存把页面加载与查询解耦。浏览器可能在一段时间内复用响应，所以一次页面浏览并不意味着一次网络请求。

相反的失误同样常见。已缓存的响应并不说明下一次刷新何时发生，而刷新计划可能与正在打开的页面无关。在把某次抓包归因于 OCSP 之前，请使用客户端当前的文档和生效的验证策略。

有效的状态响应必须满足验证方的真实性与新鲜度规则，而 HTTP 200 并不等同于良好状态。超时并不等于吊销。这些结果会导致不同的客户端行为，不应被合并成一个错误。

当查询本身敏感时，与系统所有者讨论受支持的投递与缓存选项。不要通过关闭吊销检查或链验证来解决它。

更安静的追踪并不等于更安全的连接。保持对端身份、链验证和预期吊销策略完整，只通过部署支持的选项更改投递路径。记录选择了哪个选项以及由谁负责。

当查询意外出现时，把接收方、路径和证书操作分开命名。颁发者下载、状态查询和页面请求是三件事。把它们当作一件会使隐私审查不准确，并掩盖到底哪一方学到了什么。从协议字段出发，向外推进到网络路径。