定義（用語カード）： tls-crypt-v2 は OpenVPN のクライアント固有の制御チャネル暗号化モードです。各クライアントは一意の tls-crypt 鍵（Kc）と、共有サーバー鍵で暗号化されたその鍵のラップ済みコピー（WKc）を受け取ります。接続時、クライアントは WKc を P_CONTROL_HARD_RESET_CLIENT_V3 パケット内に送信します。サーバーは Kc をアンラップし、その後双方はグループ共通の事前共有鍵ではなく、クライアント固有の鍵で制御チャネルパケットを暗号化します。

Diagram comparing pre-shared key VPN authentication concepts
出典： Wikimedia Commons — Lbutrico 事前共有鍵

OpenVPN の設定画面やプロバイダーの FAQ に「tls-crypt-v2」とある場合、それは制御チャネル保護の仕組みを指しており、データチャネルの暗号でも、独立した VPN プロトコルでもありません。この違いを理解することは、大規模フリートやホスト型 VPN プロバイダーにとって重要です。従来の --tls-auth and --tls-crypt は、すべてのクライアントとサーバーで 1 つのグループ鍵を共有します。いずれかのピアが侵害されると、その共有鍵は他の全員に対する意味のある DoS および TLS スタック保護を提供できなくなります。tls-crypt-v2 はサーバー側のラッピング鍵を共有したまま、各クライアントに独自の Kc を与えます。

設計の由来

OpenVPN はこの機能を次の文書で説明しています doc/tls-crypt-v2.txt およびプロジェクトが生成したAPIドキュメントにおける 制御チャネル暗号化（tls-crypt、tls-crypt-v2）。同じクライアント固有の方式がドラフトに記載されています OpenVPNワイヤプロトコル 「クライアント固有の暗号化キー」の項で、既存の実装ではこの機能をtls-crypt-v2と呼んでいることが明記されています。

その根拠は暗号学的であると同時に運用上のものでもあります。共有グループキーはクライアント数の増加に伴いより早く期限切れになり、漏洩したノートPCが大規模な再鍵化を強いる可能性があります。各クライアントのKcをサーバーキーで暗号化し、WKcをクライアントとともに配布することで、運用者はコミュニティ全体で共有する単一の静的キーを再配布することなく、個別のクライアントを失効またはローテーションできます。サーバーは引き続きレガシーな tls-crypt or tls-auth クライアントを移行中も受け入れることができます。V3ハードリセットオペコードが新しいモードを示すためです。

SSL VPN topology showing client, network, and server roles
出典： Wikimedia Commons — SSL VPNトポロジー

概要として、このフローは暗号化されたクッキーです：

  1. 運用者は tls-crypt-v2 を作成する サーバー クライアント鍵のラップおよびアンラップにのみ使用される鍵。
  2. 各クライアントに対して新しい Kc を生成し、サーバー鍵で WKc としてラップし、配信する Kc || WKc クライアントへ（多くの場合、次のヘッダーの PEM ブロックとして BEGIN OpenVPN tls-crypt-v2 client key).
  3. クライアントの最初の制御パケットはオペコードを使用する P_CONTROL_HARD_RESET_CLIENT_V3 そして WKc を運ぶ。
  4. サーバーは WKc を復号し、Kc をロードし、必要に応じて tls-crypt-v2-verify スクリプトをメタデータに対して実行し、その後双方が Kc を tls-crypt 方式の制御チャネル保護に使用する。

ラップされたブロブ内のオプションのメタデータには、早期のポリシーチェック（例えばクライアント識別のヒント）を含められるため、サーバーはコストの高いTLS処理を行う前に不正なハンドシェイクを中止できます。この早期中止は、大規模なマルチテナントシステムにおけるDoS耐性としてこの機能が宣伝される理由の一つです。大規模なVPNプロバイダーは特に恩恵を受けます。侵害された顧客エンドポイントが、他のすべての顧客が制御チャネルのフィルタリングに依存している単一の共有tls-cryptグループキーを自動的に露出しなくなるからです。

tls-crypt-v2が保護するもの — そして保護しないもの

tls-crypt-v2 は暗号化と認証を行います コントロールチャネル パケット：セッション鍵とオプションを交渉する TLS ハンドシェイク通信です。データチャネルの暗号（AES-GCM、ChaCha20-Poly1305 など）の代わりにはならず、出口 IP を選ぶことも、ノーログポリシーを実装することもありません。OpenVPN のコントロールプレーンを守る装甲と考えてください。認証されていない UDP ノイズや盗まれたグループ鍵が、TLS スタックに対して役立ちにくくなります。

OpenVPN 2.7.8 のリリースノート（要約元： Linux Compatible、2026年10月7日）からも、tls-crypt-v2 周りの堅牢性が今なお重要である理由が分かります。2.7.8 の修正のひとつは、鍵材料が利用できないときにラップされたクライアント鍵の再送を求めるピア要求を、クライアントが無条件に信頼しないようにしました。イタリアの CRA 政策では、この種の「悪意あるサーバーがクライアントを妨害できる」問題を、CVE 相当の機密性侵害ではなく堅牢性の低下として扱いました。それでも運用者は、tls-crypt-v2 を使うすべてのクライアントにこのパッチを入れたいと考えています。

tls-auth および tls-crypt との違い

  • tls-auth: 共有静的鍵によるコントロールパケットの HMAC のみの完全性保護であり、コントロールチャネルは暗号化しません。
  • tls-crypt: 1つの共有グループ鍵でコントロールパケットを暗号化し、認証します。
  • tls-crypt-v2: tls-crypt と同じ制御チャネル向け AEAD 方式の保護だが、クライアントごとの Kc に加え、サーバーがラップした WKc クッキーを用いる。

この3つはいずれも制御チャネルに関する話である。これらを WireGuard の Noise ハンドシェイクや IKEv2 と混同するのは、用語集でよくある誤りだ。WireGuard は tls-crypt-v2 を使わない。別経路で WireGuard を有効にしている OpenVPN 利用者は、まったく別のスタック上にいる。同様に、tls-crypt-v2 を有効にしても、古いデータチャネル暗号が魔法のように更新されるわけではなく、トンネル外の DNS リークも解消されない。

実践チェックリスト

  1. マルチクライアントの OpenVPN サーバーや VPN プロバイダーのフリートを運用しているなら、単一の共有 tls-crypt 鍵ではなく tls-crypt-v2 を優先せよ。クライアント1台の鍵漏洩でグループ鍵全体が汚染されないようにするためだ。
  2. サーバーのラッピング鍵はオフラインでバックアップし、ローテーション可能にしておくこと。そのサーバー鍵が変わったときに WKc ファイルをどう再発行するか、あらかじめ計画しておく。
  3. サーバー側で従来の tls-auth/tls-crypt を無効化する前に、クライアントが実際に V3 hard-reset（現行の OpenVPN ビルド）に対応していることを確認せよ。
  4. CVE ID が付いていない変更であっても、tls-crypt-v2 の堅牢性修正については OpenVPN 2.7.8+ を追跡せよ。
  5. 覚えておくこと：強固な制御チャネルのラッピングでは、使い回されたユーザーパスワード、フィッシングポータル、トンネル外の DNS リークは直せない。

要するに、tls-crypt-v2 は OpenVPN による「大規模展開で、壊滅的な共有静的鍵なしに制御チャネル暗号化をどう維持するか」への答えである。クッキーモデルを理解し、データチャネルとポリシーの問題は分けて考え、クライアントごとの鍵衛生を、企業専用の特殊オプションではなく通常の VPN 運用の一部として扱うこと。