OpenVPN tls-ciphersuites対tls-version-min：それぞれが何を強制するか

ほとんどのOpenVPNのTLS議論では、三つの異なる事実が一行に押し込まれています。クライアントビルドができること、プロファイルが許可すること、そしてセッションが実際に交渉したことです。短いTLS 1.3スイート一覧は真ん中の問いに半分しか答えず、プロトコルバージョンの下限については何も述べていません。以下の確認を順番にたどり、最初に成り立たないところで止めてください。後続の確認は、前の確認が済んでいることを前提とするからです。

リストを読む前にビルドを確認する

構成ディレクティブは、プロトコル対応を持たないバイナリにそれを追加することはできません。まずバージョンバナーで、コンパイルされた暗号ライブラリを確認します。

openvpn --version

OpenSSLにリンクされた2.6のビルドはtls-cipherとtls-ciphersuitesの両方を受け入れます。mbed TLSのビルドにはTLS 1.3のスイート選択がまったくなく、2.6のマニュアルはtls-ciphersuitesをOpenSSLのオプションと記しています。サーバーが別のバックエンドで再構築されれば、構成を一行も変えずに同じプロファイルの挙動が変わり得ます。

ここにいる間にopenvpn --show-tlsを実行し、出力を保存してください。それが後で比較する棚卸しであり、誰かがプロファイルを編集し始める前に押さえておくのは安上がりです。

バナーと一覧はチャットウィンドウではなく変更チケットに書いてください。六週間後にクライアントがスイートを提示できるかどうかで二人が争ったとき、取得した出力が一行で決着をつけます。

バージョン境界は暗号リストと別に保つ

2.6のマニュアルでは、これらは一つではなく三つの制御です。

• tls-cipherはTLS 1.2以前の暗号ポリシーを設定し、OpenSSLの暗号リストに渡されます；
• tls-ciphersuitesはTLS 1.3のスイートを選択します；
• tls-version-minとtls-version-maxは、接続が使用できるプロトコルバージョンを制限します。

つまり、入念に刈り込んだTLS 1.3スイート一覧は、古いバージョンがまだ許可されているかについて何も証明しません。要件が「TLS 1.3のみ」なら、それを支えるのはバージョンの下限であり、スイート一覧はその下限の中で選択肢を狭めるだけです。

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

この組は二つの仕事をします。片方の行を消せば、もう片方は思っているより弱くしか強制しません。それが、この確認全体が存在する理由の失敗です。

データチャネルは四つ目の制御です。data-ciphersはトンネル内の対称暗号を交渉し、その結果は制御チャネルのTLSバージョンについて何も語りません。セッション概要にAES-256-GCMが見えることは、どちらの方向にもTLS 1.3の証拠になりません。

show-tlsをローカルの棚卸しとして読む

--show-tlsは、このバイナリがリンクされた暗号ライブラリが対応するスイートを優先順に列挙します。ゲートウェイからの報告ではありません。マニュアルは一覧がローカルライブラリ由来だと明言しており、つまりOpenSSL 3.xのノートPCと古いビルドのルーターは、同じサーバーと話していても異なる一覧を出力します。

クライアントがスイートA、B、Cに対応し、あるセッションがBを選んだとします。それは、サーバーがAやCを許可するかにも、Bが唯一の許可された選択かにも、何も確定しません。三つの行を分けておけば、混乱したTLSの議論の大半は自然に解けます。

棚卸しはそれでも残す価値があります。セッションが失敗したとき、ライブラリの一覧とプロファイルの一覧を比べれば、クライアントがサーバーの求めるものを提示できる見込みがあったかが分かります。また、バックエンドの変更が、古いクライアントが頼るプールからTLS_CHACHA20_POLY1305_SHA256を静かに外したかどうかも分かります。他の誰も気づかないまま一部の利用者だけが接続できなくなる、あの種の回帰です。

ゲートウェイに答えられる質問をする

サービスを管理しているなら、ディスク上のファイルではなく実行中インスタンスの実効構成を調べてください。OpenVPNが別の--configパスで起動されていたり、インクルードを取り込んでいたり、編集後に再起動されていない可能性があります。クライアントが出会うのは実行中デーモンのポリシーです。

管理していないなら、運用担当者にサポート対象のクライアント要件か、範囲を限った受け入れテストを求めてください。拒否された試行は自動的に拒否されたスイートではありません。バージョンの下限、remote-cert-tlsのような証明書識別の確認、あるいはtls-authとtls-cryptの不一致が、スイート選択が問題になる前に交換を終わらせることがあります。クライアントの一覧を変える前にサーバーのエラーを読んでください。「handshake failed」は四つの異なる原因を覆い、そのうち暗号の不一致は一つだけです。

openssl s_clientをVPNポートに向けても、問いは再現されません。制御チャネルはOpenVPN自身のフレーミングの中で動くので、生のTLSプローブは別のものを期待するポートで別のプロトコルを試すことになります。そこから得られる結論はプローブについてであり、トンネルについてではありません。

二つの結果を記録し、分けて保つ

新しく許可されたセッションは、プロトコルバージョンと選択された暗号を記す制御チャネルの行と、トンネルの暗号を記す別のデータチャネルの行を生みます。どちらもクライアントのバージョンとプロファイル名とともに取得し、どのサーバーインスタンスが応答したかを書き留めてください。

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

そのうえで、二行は記憶ではなくそのファイルから読んでください。この組が証拠です。スイート名だけは好みであり、バージョン境界はサーバーが何を拒むかについての別の表明です。

確認はこの順で行います。--versionでビルドとバックエンドを確かめます。何かを変える前に--show-tlsを取得します。必要なバージョン下限をスイート一覧とは別に述べます。実行中インスタンスの実効ポリシーを所有者と確認します。許可されたセッションを一つ観察し、計画が許せば古いバージョンでの拒否された試行も一つ観察します。制御チャネルとデータチャネルの結果を別々の所見として記録します。

必要なクライアントが新しい最小要件を満たせないなら、展開が完了したように見せるために無関係な受け入れ規則を静かに下げるのではなく、その移行または例外の判断を明示的に下してください。