VPN の背後にあるキャッシュ: HTTPS が今も隠すもの

VPN サーバーの隣にキャッシュを置けば、トンネルの内側の全員に無料の帯域が手に入るように聞こえます。そうではありません。その地点を通るバイトは、ブラウザとサイトを両端とする TLS セッションで保護されたままです。VPN ゲートウェイが外すのは自分自身の外側の暗号化だけで、アプリケーションの暗号化ではありません。ハードウェアを増やす前に、どの繰り返しオブジェクトを再利用するのかを決めます。

TLS セッションはブラウザのもの

通常の HTTPS では、ブラウザがサイトと鍵を交渉し、ハンドシェイク後の各レコードはその両端の組に向けて暗号化されます。VPN ゲートウェイは自分が作ったトンネルを復号し、その後に不透明な TLS レコードを転送します。見えるのは宛先、時刻、量であり、リクエスト行やレスポンス本文ではありません。これが、あらゆるキャッシュが従うべき境界です。

これを破る設計は TLS 傍受の設計であり、証明書の信頼と端末管理に独自の帰結をもたらします。

CONNECT はトンネルであり、キャッシュではない

明示的フォワードプロキシは通常 HTTP CONNECT 要求を受け取り、その後に双方向へバイトを中継します。要点は中継です。プロキシは暗号化された会話を解析していません。

curl -sSI -x http://proxy.example:3128 https://example.com/

レスポンスヘッダーはプロキシのトンネル処理から来るもので、ページのキャッシュ複製からではありません。CONNECT の成功は経路が動くことを意味し、再利用のために何かが保存されたことを意味しません。 ポート 443 をキャッシュに向けても TLS を話せるようにはなりません。キャッシュには読めるメッセージが必要だからです。クライアント設定は、説明のないリダイレクトではなく、対応する明示的プロキシ設定を使う必要があります。

運用するものをキャッシュし、閲覧するものはしない

コンテンツが自分のものであれば、リバースプロキシが TLS を終端し、承認済みのレスポンスを意図的に保存できます。パッケージリポジトリに属する場合は、プロジェクトが対応するミラーを使います。

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

最初のコマンドはキャッシュゾーンが設定されているかと適用範囲を示し、二つ目は一つのオブジェクトに対するオリジン自身のキャッシュ指示を示します。共有キャッシュは鮮度、キャッシュ制御、表現を区別する要求属性を守る必要があります。 private と no-store は異なる意味を持ち、ヒット率を上げるためにどちらも削ってはいけません。HTTP のキャッシュ規則は認証済み要求へのレスポンス保存も制限しており、まさにそこが個人向けページのデータ露出になります。プロキシは開いたリレーとして公開せず、承認済みクライアントに限定します。

ヒットを測り、ストップウォッチは測らない

二回目の要求が速いことは、新しいキャッシュが何かをした証拠になりません。ブラウザや OS が自ら積極的にキャッシュするからです。プロキシにヒットとミスのカウンターを尋ね、統制された繰り返しの間にオリジンの通信を見ます。既知のオブジェクトを一度繰り返しダウンロードし、キャッシュを有効にした場合と迂回した場合で、経過時間ではなくオリジンが配信したバイトを比べます。次に認可の境界を確認します。ログインを要するリソースを別のクライアントに返してはいけません。

ワークロード、キャッシュキー、再利用を許したポリシーを記録します。キャッシュは最適化の衣装を着たデータ共有の判断です。