OpenVPN で dh none と RSA 証明書は併用できる？

ここに、RSA と書かれた証明書の隣に dh none と書かれたサーバー設定があります。さらに、どちらかが必ず間違っているという嫌な疑いも付いてきます。何も間違っていません。証明書は署名と認証を行い、鍵交換は共有秘密を確立します。これは同じハンドシェイクの中の二つの別の仕事であり、TLS は RSA 証明書が一時的な楕円曲線合意を使うハンドシェイクを認証することを許します。

混乱はたいてい移行ガイドとともにやってきます。DH パラメーターファイルを dh none に置き換えるよう書かれており、読者は証明書が楕円曲線証明書ではないことに気づき、その二つの事実が矛盾として扱われます。

二つの設定が関連して見える理由

OpenVPN の古い設定が DH パラメーターファイルを要求したのは、有限体 Diffie-Hellman が双方の合意するドメインパラメーターを必要とするからです。dh ディレクティブはそのファイルを指していました。展開が ECDH に移ると、パラメーターは代わりに名前付き曲線から供給され、ファイルは不要になります。それが dh none の意味です。

証明書は別の軸です。証明書はサーバーの身元を証明する公開鍵と署名を持ち、その鍵はセッション鍵の合意方法とは関係なく RSA でも楕円曲線でもかまいません。鍵合意に ECDHE、認証に RSA を使うハンドシェイクはありふれたもので、広く展開されています。

命名が重なりを悪化させます。楕円曲線は ECDHE と ECDSA の両方のスイート名に現れるため、曲線に言及する接続には必ず曲線証明書が必要だと誤解しやすくなります。そうではありません。

TLS 1.2 のスイート名を正しく読む

ECDHE-RSA-AES256-GCM-SHA384 を例に取ります。最初のトークンは鍵交換ファミリーで、一時的な楕円曲線 Diffie-Hellman です。二つ目は認証ファミリーで、RSA です。残りはレコード保護とハンドシェイクで使われるハッシュを表します。

ECDHE-ECDSA スイートは同じ鍵交換ファミリーを別の認証方式で使うため、楕円曲線証明書が必要です。DHE-RSA スイートは有限体の一時的 Diffie-Hellman と RSA 認証を使い、こちらは実際に DH パラメーターが必要です。

スイート名を左から右へ読み、各部分をその仕事に割り当てます。トークンを分離すると、問いは「自分の証明書は dh none と一致するか」から「自分のサーバーは鍵交換に DH ファイルを必要としないスイートを許可しているか」に変わります。

dh none が実際に無効にするもの

dh none は、有限体 DH パラメーターファイルを読み込まないようサーバーに指示します。認証、証明書検証、TLS 自体を無効にするわけではありません。ただし、交渉された鍵交換がそれらのパラメーターを必要としないものであることを要求し、実際には ECDHE スイートか TLS 1.3 ハンドシェイクを意味します。

その要件から破綻が生まれます。サーバーの TLS 暗号ポリシーが DHE スイートに限定されている場合、またはクライアントがそれしか提示しない場合、パラメーターファイルを削除すると使える鍵交換方式が残らず、ハンドシェイクは失敗します。エラーは通常、制御チャネルのハンドシェイク中、ユーザー認証より前に現れます。欠けているファイルを責める前に暗号リストを読んでください。

楕円曲線側では、曲線はサーバーの TLS 設定によって選ばれ、OpenVPN は古いブランチでそれを選ぶオプションを提供します。TLS 1.3 はグループ交渉をプロトコル内部で処理し、DH ファイルをまったく参照しません。

dh none 自体はセキュリティの低下ではありません。交換の強さは実際に交渉された曲線とスイートに依存するため、次の一歩は欠けているファイルではなく、ピアが何を選んだかを見ることです。

編集前に交渉を確認する

サーバーとクライアントの冗長度を上げ、接続後に OpenVPN が出力する制御チャネルの行を読みます。そこには TLS バージョンと交渉された暗号が示され、ピア証明書の鍵種別も報告されます。その一行が、設定ファイルがほのめかすだけの問いに答えます。

TLS 1.2 と ECDHE-RSA スイート、RSA 証明書が表示されていれば、その組み合わせは dh none が期待するとおりで、直すものは何もありません。DHE スイートや共通暗号のないハンドシェイク失敗が表示されるなら、修正は暗号ポリシーかクライアントの能力にあり、証明書ではありません。

サポートする予定の最も古いクライアントをテストしてください。現在のクライアントは TLS 1.3 を交渉できますが、古いクライアントは TLS 1.2 スイートに限られることがあります。最も古いクライアントに重なりがない場合は、許可するスイートを広げるか、そのエンドポイントを更新してください。

ハンドシェイク失敗を回避するために証明書検証をオフにしないでください。失敗は、ピア同士が鍵交換で合意できなかったことを示しており、検証を切ると合意を解決しないまま身元保証を失います。

チェックリスト：証明書は RSA か、ECDHE スイートは許可されているか、ログにそのスイートが出ているか、サポートする最も古いクライアントもそれを交渉するか。四つすべてがはいなら、dh none は仕事をしています。