OpenVPN tls-crypt-v2: クライアント鍵とラップされた blob の役割

tls-crypt-v2 プロファイルをチケットに貼り付けるのは、ファイルの中身を数えるまでは無害に見えます。クライアントの制御チャネル鍵は同じ鍵の暗号化コピーの隣にあり、三つ目のオブジェクトであるラップ鍵は受け入れるサーバーから決して出ません。この三つは保管、共有、廃止について異なる問いに答えます。これらを分けておけば、ほとんどのポリシー論争は始まる前に決着します。

プロファイルに実際に含まれるもの

tls-crypt-v2 のクライアント側の半分は、鍵とそのラップされたコピーです。クライアントは平文の鍵を制御チャネルの保護に使い、セットアップ中にラップされたコピーをサーバーに渡すので、サーバーはクライアントごとに平文コピーを保存せずに同じ鍵を復元します。ラップ鍵はその復元を可能にし、受け入れる側だけに属します。以下はすべて、この三つのオブジェクトがどこにあるかから導かれます。

表を名前ではなく保管の観点で読めば、結果は自然に出てきます。ラップ鍵を失うのが高くつく出来事で、プロファイルの中の何もそれを再構築できず、正直な復旧はグループの再発行です。漏えいしたプロファイルは安く済みますがはるかに多く、ラップされたコピーがあればファイルを共有しても安全だと信じる人がチケットに貼り付けます。二つの失敗には別々の対応が必要で、だからこそオブジェクトを分けておきます。

ラップされたコピーだけでは足りない理由

プロファイルは使えるクライアント素材をラップされた対のコピーと一緒に持ち運ぶので、サーバー用のコピーを守ることはファイルを守ることについて何も言いません。blob は送信には安全で、公開には安全ではありません。中のメタデータは blob を受け取った誰にでも見え、貼り付け先のチケットを後で読む人にも見えます。

プロファイルは設定の見本ではなく資格情報として扱います。漏えいしたファイルは、サーバーがその身元を受け付けなくなるまで、保持者に有効なクライアント身元を与え、ラップはその時間帯について何もしません。クライアントごとに一つのプロファイルを発行して取り消しを単一ファイルの判断に保ち、ラップ鍵のバックアップはそれが有効にするサーバー設定とは別に取ります。どちらの習慣も侵害されたプロファイルを修復しませんが、どちらも次の一件をどれだけ早く封じ込めるかを決めます。

検証フックがハンドシェイクのどこに座るか

検証フックは TLS スタックが公開される前に実行され、その仕事はラップされた blob に含まれるメタデータを調べることです。フックはそのメタデータと小さな文書化された環境を受け取り、認証フックより扱える材料が少なくなっています。ユーザー名、セッション状態、プラグイン変数が見えると仮定するのが、このフックを下手に書くいつものやり方です。別のフックから期待を借りるのではなく、そのフック自身のマニュアルの節を読んでください。

終了ステータス、すなわちゼロ以外の結果はクライアントを拒否し、ゼロの結果はハンドシェイクを続行させる値が判断です。したがってポリシーは、メタデータが欠けている場合、解析できない場合、想定外の場合に何が起きるかを定めなければなりません。まず拒否の経路を書き、そのあとでどの値を受け入れるかを決めます。

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

この二行がサーバー上のポリシー面で、一方はラップ鍵を名指しし、もう一方は各クライアントを判定するプログラムを名指しします。興味深いことはすべてスクリプトの中にあり、他のアクセス規則と同じくバージョン管理とレビューに値します。

アカウント、証明書、制御鍵は別々に廃止する

TLS の身元確認より前でアカウントの認可より前に起きるため、制御チャネルの早期受け入れは認証ではない。アカウントの無効化、証明書の失効、クライアント制御鍵の拒否は、三つの仕組みを持つ三つの行為です。そのうち一つしか行わない配備には、ポリシーではなく隙間があります。三つを意図的に突き合わせ、どの手順がどの権限を行使するかを記録します。

タイミングが二つ目の区別です。変更された受け入れリストは新しいハンドシェイクに適用され、すでに確立したセッションは何かが終了させるまで動き続けます。新しいリストの項目を、古いセッションが終わった証拠と数えるのが、削除したクライアントが何時間もつながったままになる理由です。

突き合わせていない権限は、実務で見つけやすい二つの穴を残します。アカウントが無効でも制御鍵がまだハンドシェイクを開き、証明書が失効してもメタデータポリシーが同じクライアントをまだ受け入れます。どちらも別の場所での同じ誤りで、運用者が一つのリストを権限の全体と見なした結果です。削除の時点で三つのリストを並べれば、誤りは見えるようになります。

プロファイルの発行と取り消し

発行は簡単な半分で、受け入れる側でクライアント鍵を作り、プロファイルをちょうど一人の所有者に渡し、ラップ素材を制限して保ち、すべての受け入れるサーバーで同じ検証プログラムを実行します。安価な受け入れはグループ全体の性質であり、最新のホストの性質ではありません。古い、または緩いスクリプトを持つ二台目のサーバーは、静かに配備で最も弱い経路になります。

取り消しには三つの手順を意図した順序で行います。検証フックでクライアントを拒否して新しいハンドシェイクを失敗させ、PKI を使っているなら証明書を失効させ、アカウントを無効にして後の認可に認可するものを残しません。次に、三つのどれもセッションには気づかれないため、古い受け入れが許していたセッションを終了させます。壊してもよいクライアントで手順を練習します。

プロファイルのメタデータはそのポリシーへの入力であり、アクセス制御がすでにある証拠ではありません。OpenVPN 2.6 の設計文書はオブジェクトとそれらが引く境界を説明し、強制は運用者に残ります。