OpenVPN ログ：制御チャネルの暗号とデータチャネルの暗号

ログに DHE-RSA-AES256-SHA と表示されても、それは接続全体の要約ではありません。これは制御チャネルを保護する TLS ハンドシェイクに属するもので、トンネル内の通信はまったく別の方式で暗号化されることがあります。これを VPN のデータ暗号として報じるのが避けるべき誤りです。

重要な結果は二つあり、それぞれ別の問いに答えます。一つは制御チャネルでネゴシエートされた TLS スイート、もう一つはトンネルが運ぶパケットのデータ暗号です。

二つの結果、二つの問い

制御チャネルはハンドシェイクとピア間の管理メッセージを運びます。その暗号は TLS スタックが選ぶため、名前は TLS の慣例に従います。データチャネルは利用者の通信を運び、OpenVPN 自身の暗号ネゴシエーションで設定されます。

どちらの行を読む前に、どちらの問いに答えているのかを決めてください。トンネルが暗号化されているかどうかと、ハンドシェイクが強固かどうかは同じ問いではありません。

両方の行を示すログの抜粋が役に立ちます。TLS のバージョンとスイートは制御側の行で、ペイロードを実際に保護するアルゴリズムはデータ側の行で読んでください。

TLS スイート名をその文脈で読み解く

OpenSSL 風の歴史的な名前、例えば DHE-RSA-AES256-SHA では、各構成要素が別々の決定を表します。 DHE は一時的な Diffie-Hellman 鍵合意、RSA は認証方式、AES256 は TLS レコードの CBC モードにおける AES-256、SHA は SHA-1 ベースのレコード MAC です。

最後の要素は証明書のフィンガープリントではなく、そう読むのはよくある誤りです。名前だけではプロトコルのバージョンもわからないのは、TLS 1.3 がまったく別の命名方式を使うからです。TLS_AES_256_GCM_SHA384 はその新しい形式に従っており、末尾のハッシュは MAC の選択ではなくスイートの構成の一部です。構成要素ごとの読み方は古い命名方式にだけ当てはめてください。

OpenSSL のスイート一覧 では、なじみのない構成要素があれば、これらの名前と定義の対応を確認できます。

運ばれる通信についてデータチャネルの結果を読む

運ばれる通信については、同じセッションのデータチャネルの行を読んでください。設定ファイル内の data-ciphers の一覧は許可された集合であり、特定のアルゴリズムがネゴシエートされた証拠ではありません。ログは選択を記録し、設定ファイルは候補の一覧を記録します。

AES-GCM のような AEAD 暗号は自前の完全性検査を伴うため、データチャネル用の別個の HMAC はその経路には含まれません。

auth ディレクティブは TLS、証明書、データ暗号を強化するものではありません。まだダイジェストを使う部分のためにダイジェストを選ぶもので、AEAD のデータ暗号では設定すべき別個のデータ HMAC はありません。

本人確認を暗号の結果から切り離す

証明書の署名アルゴリズム、信頼チェーンの検証、ピア名の確認はさらに三つの性質であり、暗号名はそれらについて何も語りません。有効期限切れの証明書はスイートがどれほど強くても失敗します。サーバー名の不一致も同じように失敗します。プロファイルのダイジェスト設定を直しても、どちらも修復されません。

これらの確認は暗号の結果の隣に、統合せずにレビュー用のメモとして残してください。

現在のセッションからネゴシエートされた結果を記録する

現在の接続から結果を取り、クライアントとサーバーのバージョンも併せて記録してください。追記専用のログには古いセッションの行が残ることがあり、それを現在のものとして引用すると、直した問題が続いているように見えます。

ポリシーレビューでは、ネゴシエートされた TLS のバージョンとスイート、選ばれたデータ暗号、証明書検証の設定をまとめて設定の所有者に渡してください。その層を変更したら、新しいログを読んで新しいネゴシエート値を確認します。