Privacy Proxy は、トラフィックをプロキシする前にクライアントの認証を求めます。このページでは、対応する認証方法と、それぞれの使いどころを説明します。
Privacy Proxy は 3 つの認証方法をサポートします。
| 方法 | 用途 | プライバシーの度合い |
|---|---|---|
| 事前共有鍵（PSK） | 概念実証、テスト | 低 |
| Privacy Pass トークン | クライアントからサーバー | 高 |
| mTLS | サーバー間 | より高い |
事前共有鍵は、開発と概念実証のテストで認証する簡単な方法です。Cloudflare がシークレットキーを提供し、クライアントは各リクエストに含めます。
Proxy-Authorization ヘッダーに PSK を含めます。
CONNECT example.com:443 HTTP/2
Host: example.com
Proxy-Authorization: Preshared <YOUR_PSK>プロキシはキーを検証し、一致すれば接続を許可します。
PSK 認証には制限があり、本番には向きません。
- 共有シークレット: すべてのクライアントが同じキーを使うため、個別ユーザーのアクセスを失効できません。
- ユーザー単位のレート制限なし: ユーザーごとの割り当てや上限を適用できません。
- リクエストの紐付け: 同じ PSK を使うすべてのリクエストをプロキシが関連付けできるため、ユーザーのプライバシーが下がります。
PSK はテスト専用です。本番デプロイでは Privacy Pass トークン を使ってください。
Privacy Pass ↗ は、身元を明かさずにクライアントが認証できるプロトコルです。トークンは暗号的に紐付けできないため、プロキシは同一ユーザーからの異なるリクエストを関連付けできません。
Privacy Pass は三者構成です。
- Attester: Client が正当なユーザーであること（有効なアカウントを持っているなど）を確認し、トークンリクエストを Issuer へ転送します。
- Issuer: どの Client がリクエストしたかを知らずに、ブラインドトークンに署名します。
- Origin（Privacy Proxy）: 認可の証明としてトークンを受け付けます。
┌──────────┐ 1. Attestation request ┌──────────┐
│ │ ──────────────────────────▶ │ │
│ Client │ │ Attester │
│ │ ◀────────────────────────── │ │
└──────────┘ 2. Attestation OK └──────────┘
│
│ 3. Blinded token request
▼
┌──────────┐ 4. Forward request ┌──────────┐
│ │ ──────────────────────────▶ │ │
│ Attester │ │ Issuer │
│ │ ◀────────────────────────── │ │
└──────────┘ 5. Signed blinded token └──────────┘
│
│ 6. Return to Client
▼
┌──────────┐
│ Client │ (unblinds and stores token)
└──────────┘Client はリクエストを紐付けされないように、Attester 経由でトークンリクエストを送ります。Issuer は、トークンリクエストを特定の証明イベントや Client の身元と関連付けできません。
┌──────────┐ 1. Present token ┌──────────┐
│ │ ──────────────────────────▶ │ │
│ Client │ │ Privacy │
│ │ ◀────────────────────────── │ Proxy │
└──────────┘ 2. Connection OK └──────────┘Privacy Proxy は Issuer の公開鍵でトークンを検証します。プロキシが知るのはトークンが有効であることだけで、誰に発行されたかは分かりません。
トークン発行の流れは次のとおりです。
- クライアントは Attester に身元を証明します（アカウントでサインインするなど）。
- Attester はクライアントが正当であることを確認します。
- クライアントはブラインドトークンを生成し、Issuer へ送ります。
- Issuer はブラインドトークンに署名して返します。
- クライアントはブラインドを解除し、トークンを保存します。
リクエスト時の流れは次のとおりです。
- クライアントは
Proxy-Authorizationヘッダーにトークンを含めます。 - プロキシは Issuer の公開鍵でトークン署名を検証します。
- トークンが有効なら、プロキシは接続を許可します。
発行時にトークンがブラインドされているため、Issuer はトークンを特定の発行リクエストに紐付けできません。プロキシが見るのはトークンが有効であることだけで、誰に発行されたかは分かりません。
Privacy Pass トークンは、PrivateToken スキームで Proxy-Authorization ヘッダーに含めます。
CONNECT example.com:443 HTTP/2
Host: example.com
Proxy-Authorization: PrivateToken token=<base64-encoded-token>Privacy Pass を使う本番デプロイでは、次を行います。
- Issuer を選びます。Cloudflare がトークン Issuer を運用することも、サードパーティの Issuer と連携することもできます。
- クライアントがトークンを受け取る前に身元を証明する方法として、Attestation を設定します。
- Issuer の設定を配布します。クライアントがトークンをリクエストするには、Issuer の公開鍵とエンドポイントが必要です。
デプロイ向けに Privacy Pass を設定するには、お問い合わせ ↗ください。
相互 TLS（mTLS）認証 ↗ は、双方向でトラフィックを安全かつ信頼できる状態にします。クライアントはプロキシに証明書を提示し、プロキシは接続を許可する前に検証します。
クライアントは TLS ハンドシェイク時に TLS クライアント証明書を提示します。プロキシは設定した認証局（CA）に対して証明書を検証し、信頼できる証明書なら接続を許可します。
クライアントまたはサービスごとに証明書を発行し、管理する必要があります。mTLS はサーバー間通信向けであり、個人ユーザーの認証には向きません。プロキシは証明書でクライアントを識別できるため、Privacy Pass と比べてプライバシーは下がります。
双方が信頼できるサービスであるサーバー間連携では、mTLS を使ってください。
ダブルホップデプロイ では、認証は 2 段階で行われます。
Proxy A（運用するのはあなたです）がユーザーを認証します。よく使う方法は次のとおりです。
- アカウント認証情報（ユーザー名 / パスワード、SSO）
- 自前のインフラが発行する Privacy Pass トークン
- クライアント証明書（mTLS）
Proxy B は TLS で Proxy A に対して自身を認証します。設定によっては、次を使えます。
- 標準の TLS 証明書
- 証明書のオーバーヘッドを減らす Raw Public Key（RPK）TLS 拡張
- Privacy Pass Working Group ↗ — Privacy Pass プロトコルを策定している IETF ワーキンググループです。
- Supporting the latest version of the Privacy Pass protocol ↗ — Privacy Pass の実装についての Cloudflare ブログ記事です。