auth ダイジェストが保護する OpenVPN パケットはどれか

OpenVPN のダイジェストをめぐる議論の多くは、見当違いのパケットから始まる。auth SHA256 を「SHA256 を提示するピアだけを受け入れる」と読むのは、まず捨てるべき思い込みだ。このオプションは特定のパケットに対するダイジェストを指定するもので、どのパケットかはチャネルと、そのチャネルが AEAD かどうかで変わる。以下の四つの問いを順にたどると、この設定があなたの配備で何を意味しうるかが絞り込める。

設定が守るべきチャネルを特定する

OpenVPN には TLS ハンドシェイクの通信を運ぶ制御チャネルと、トンネルのペイロードを運ぶデータチャネルがある。auth ダイジェストはどちらにも役割を持つが、同じ役割ではなく、その違いがプロファイルから見えることはほとんどない。設定ファイルに触れる前に、どちらを制限しようとしているのかを書き出しておく。

次の表は、同じオプションが各文脈でどう働くかの短いまとめだ。

データチャネルが AEAD かどうかを、頼る前に確認する

折衝されたデータ暗号が AES-GCM か CHACHA20-POLY1305 なら、データチャネルは自らを認証するので、別のダイジェストがあなたの思い描く仕事をしているわけではない。どちらも AEAD の構成であり、完全性はペイロードを暗号化するのと同じ演算で生まれる。これは水準の低下ではないが、「すべてのデータパケットは HMAC-SHA256」という理由づけの方針は、そのトンネルでは事実として誤りだ。方針を書き換える前に、折衝された値をサーバーのログかクライアントの状態出力で確認する。

折衝は集合の別の要素に落ち着くことがあるので、プロファイルの一覧ではなく実際に折衝された暗号を調べる。data-ciphers AES-256-GCM:AES-128-GCM は折衝用の一覧であり、どちらの項目も AEAD なので、どちらもペイロード保護のために auth ダイジェストを消費しない。

制御チャネルの保護は独立した判断として扱う

tls-auth は制御チャネルのパケットに HMAC を加え、そのダイジェストを auth 設定から取るので、AEAD のトンネルでも意味のあるダイジェストを設定できる。tls-crypt は独自の固定保護を持つ別の仕組みなので、tls-auth のあらゆる性質を引き継ぐと決めつけない。仮定を移し替えるのではなく、選んだ仕組みの文書を読む。

二人のピアは仕組みと鍵の向きについても合意しなければならない。ダイジェストは一致しても、鍵ファイルを逆向きに使えば、ダイジェスト設定では説明できない理由でハンドシェイクが失敗する。

auth は暗号の折衝や証明書とは切り離しておく

三つの設定、すなわち auth ダイジェスト、データ暗号の一覧、証明書の署名アルゴリズムがしばしば混同される。一つ目を変えても証明書は再発行されず、署名ダイジェストも選ばれず、ユーザーとパスワードの方式も生まれない。プロトコルオプションの定義は OpenVPN 2.6 のソース でそれぞれ独立した節に書かれており、これらが別々の調整項目であることを思い出させてくれる。

ダイジェストを変えた後にピアが接続を拒むなら、原因はたいてい残り二つの設定のどちらかの不一致だ。どちらかを変える前に双方を読む。

方針を書き出し、稼働中の設定と比べる

全体の方針を示す文は、許可するデータチャネルの方式と選んだ制御チャネルの保護を、同じ一文で明示すべきだ。その一文は検証できるが、「SHA256 を使っている」では検証できない。そのうえで、リポジトリの雛形ではなく、実際に効いているサーバーとクライアントのプロファイルと突き合わせる。

各トンネルが実際に何を折衝し、どの仕組みがパケットを認証したのかを記録して締めくくる。プロファイルに見える auth の行は設定意図の証拠にすぎず、意図は確認作業で最も安く済む部分だ。