OCSP のプライバシー：応答者が見るのは証明書で、URL ではない

ステータス確認は一つの証明書について一つの問いを投げ、その答えは独自の接続で運ばれる。確認のきっかけとなったページのパスは含まれない。プライバシーの議論では、このやり取りを閲覧履歴のフィードのように扱うことが多いが、それはリクエストが運ぶものを過大に見積もり、応答者が観測できるものを過小に見積もっている。何が明らかになるかを判断する前に、リクエストを読んでほしい。

リクエストが特定するのは一つの証明書

OCSP の証明書識別子は、ハッシュ関数、発行者の二つのハッシュ、対象証明書のシリアル番号から構築され、これは RFC 6960 に規定されている。各フィールドが指すのは一つの証明書であり、URL や HTTP リクエストではない。

ページのパス、クエリ文字列、フォームの内容は、標準の識別子には含まれない。応答者が正確な URL を受け取るという主張には、証明書の確認以外の場所からの根拠が必要だ。リクエストは依然として証明書と時刻を示しており、応答者はそれを提示するサービスを知っているかもしれない。

欠けているのはページであり、文脈のすべてではない。証明書の確認に既知のサービスと繰り返される発信元を加えると、どれか一つだけより多くのことを示せる場合がある。

応答者が実際に観測できるもの

応答者が見るのは、自分に届く接続であり、それには発信元アドレス、タイミング、配備が記録するあらゆる転送メタデータが含まれる。ステータスリクエストが VPN を通る場合、その発信元は利用者のアクセス網ではなく VPN の出口かもしれない。同じブラウザセッションに属するというだけで、ステータスリクエストがページリクエストと同じ経路を通ると決めつけてはいけない。

単一のトレースから推測するのではなく、クライアントが対応するルーティングと検証の挙動を確認すること。分割トンネルでは、二つのリクエストが別々の方向へ送られることがある。

ステープルされた応答が、もう一つの一般的なパターンだ。RFC 6066 の TLS status_request 拡張により、サーバーは自身のハンドシェイクに OCSP 応答を添付でき、そのためクライアントは、その接続のために自分でステータスを取得するのではなく、与えられたものを検証する。この移行は観測者を変える。取得を行うのはサーバー側であり、クライアント自身のアドレスがその接続で応答者に届くことはない。

ステータスはハンドシェイク内でステープルされて届くことがある

これらのどれも、クライアントが二度と別の検証リクエストを行わないことを保証しない。チェーンの構築、ステータスの方針、対応する仕組みは実装によって異なる。

一つのブラウザの証明書ビューアは、すべての OS と VPN クライアントを説明するものではない。同じネットワークキャプチャでも、検証設定が違えば意味は変わる。

キャッシュは一ページ一照会という前提を崩す

キャッシュはページの読み込みと照会を切り離す。ブラウザは一定期間応答を再利用できるため、一回のページ閲覧が一回のネットワークリクエストを意味するわけではない。

逆の誤りも同じくらい多い。キャッシュされた応答は、次の更新がいつ起きるかを何も語らず、更新の予定は開いているページと無関係かもしれない。キャプチャを OCSP に結びつける前に、クライアントの現在の文書と有効な検証ポリシーを使うこと。

有効なステータス応答は、検証者の真正性と鮮度の規則を満たす必要があり、HTTP 200 は良好なステータスと同じではない。タイムアウトは失効ではない。これらの結果は異なるクライアントの挙動につながるので、一つのエラーにまとめるべきではない。

検証を保ったままにするプライバシー上の選択

照会そのものが機微な場合は、対応している配信とキャッシュの選択肢をシステムの所有者と話し合うこと。失効確認やチェーン検証を切ることで解決してはいけない。

静かなトレースは安全な接続ではない。ピアの身元、チェーン検証、意図した失効ポリシーを保ち、配信経路は配備が対応する選択肢を通じてのみ変えること。どの選択肢を選び、誰がそれを所有するかを記録すること。

照会が思いがけず現れたときは、受け手、経路、証明書の操作を別々に名指しすること。発行者からのダウンロード、ステータスの問い合わせ、ページリクエストは三つの出来事だ。それらを一つとして扱うとプライバシーレビューは不正確になり、どちらの当事者が実際に何かを学んだのかが隠れる。プロトコルのフィールドから始め、外側へネットワーク経路へと進むこと。