Linux での AnyConnect の不正な TLS バージョン: まず修正の範囲を決める

このエラーはパスワード入力の前に出ます。そこが有用な点で、まだ何も認証されていないため、資格情報が原因ではありません。Linux では同じ AnyConnect のダイアログが、古いプロトコルバージョン、1024 ビットの鍵交換グループ、あるいはシステムの暗号ポリシーが拒否する暗号スイートから出ることがあります。私は三台のマシンで三つの異なる方法によりこれを解消しました。これらの修正を分けるのは巧みさではなく、影響の範囲です。どれも正しい場所では妥当で、それ以外では悪い既定値です。

ポリシーに触る前にメッセージを読む

ダイアログの正確な文字列を控えます。バージョンの不満はプロトコル層を、証明書の不満は信頼か名前を、ログインの失敗は資格情報を示します。TLS 1.0、1024 ビットの DHE グループ、AES-256-CBC、SHA-1 署名を提示するゲートウェイは、完全に有効な証明書を持っていても、資格情報が送られる前に現代のポリシーで拒否されます。

システムの OpenSSL で端点を調べます。実際のホスト名と、クライアントが使うポートを使ってください。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com が失敗し -tls1 -cipher DEFAULT@SECLEVEL=0 が成功するなら、境界はバージョンと鍵長の両方です。最初のコマンドがプロトコルの警告ではなく小さな DH 鍵を報告するなら、バージョンは問題なく、グループだけに注意が必要です。調べる際に秘密鍵やパスワードを決して入れないでください。

選択肢 1: 暗号ポリシーでホスト全体を緩める

Fedora と RHEL 8 および 9 では、update-crypto-policies --set LEGACY が OpenSSL のシステムポリシーを下げ、update-crypto-policies --show が何が有効かを確認します。通常はトンネルが戻りますが、ポリシーはプロセス開始時に読まれるため、再試験の前にクライアントとそれが起動した補助プロセスを再起動してください。また、マシン上のすべての TLS クライアントに古いプロトコルと弱いグループを許します。隣のウィンドウのブラウザから、カーネルを更新するパッケージマネージャまでです。

この広さが目的そのものであり、問題そのものです。LEGACY はホスト全体にわたり、永続的で忘れやすく、管理されたビルドでは診断手順か文書化された例外であるべきで、ワークステーションの常態にしてはいけません。二年前から LEGACY のままの一台を見たことがあります。社内ポータルが一つだけそれを必要としていたためで、誰もいつ始まったか言えませんでした。

Debian と Ubuntu にはこれの単一のスイッチがありません。相当するのは /etc/ssl/openssl.cnf の編集で、システム既定の節に低い MinProtocol と CipherString = DEFAULT@SECLEVEL=0 を設定します。範囲は同じでファイルが違い、リリース更新の間に見失いやすいだけです。

選択肢 2: 一つのクライアントに一つの設定ファイル

プロセス単位の OpenSSL 設定は変更を一つのプロセスツリー内に保ちますが、ファイルがライブラリの期待どおりに配線されている場合に限ります。ssl_conf 節に名前を付けるだけでは足りません。OpenSSL は最上位の openssl_conf キーを読み、それを初期化節へたどり、そこで初めて SSL の既定値に到達します。

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF をそのファイルに向け、それをエクスポートするラッパー経由で VPN クライアントを起動します。ホスト上の他のすべては既定のポリシーを保ち、準拠の問いが来たときに重要なのはこの性質です。ゲートウェイを責める前にファイルが本当に効いていることを確認してください。OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 は TLS 1.0 の暗号を並べるはずで、空の結果は連鎖が切れてクライアントが黙ってシステム既定を使ったことを意味します。

ファイルはバージョンに敏感です。OpenSSL 1.1.1 と 3.x は同じ節名を受け付けますが、プロバイダ周りの指示の扱いは 3.x で変わりました。ファイルが読まれたと決めつけず、クライアント自身のログと試験的なハンドシェイクで確かめてください。節名の打ち間違いは開いたまま失敗し、クライアントは黙ってシステム既定を使います。

限界は範囲です。GnuTLS や NSS にリンクされたものは OPENSSL_CONF を無視し、クライアントが環境を継承せずに起動する補助プロセスも同じです。ラッパーを作る前に ldd でバイナリが実際にどの TLS ライブラリにリンクされているか調べてください。答えがこの選択肢の存在自体を決めます。

選択肢 3: 使い捨ての VM かコンテナ

二週間だけ古い一つのゲートウェイを叩く請負業者には、緩めたポリシーの専用 VM がワークステーションよりきれいな境界です。古い面と日常のブラウザプロファイルがカーネルポリシーを共有しなくなり、廃棄は削除であって監査の指摘ではありません。

それでもネットワーク上のマシンなので、アクセスを制限し、一般の閲覧から遠ざけてください。保守費用はパッチを当てるイメージが一つ増えることで、現実ですが限られ、目に見えます。ノート PC に忘れられた LEGACY フラグとは違います。

比較が残すもの

三つの問いで選びます。古いプロトコルを誰が、いつまで必要とし、例外が理由より長生きしたら誰が気づくか。一つのアプリ、一人、数日ならプロセス単位の設定です。一つの機器の後ろの全艦隊ならゲートウェイ自体です。ホストに恒久的な LEGACY ポリシーを要するものは、技術の衣装を着た調達の判断です。

恒久的な修正は機器側にあります。TLS 1.2 以降、少なくとも 2048 ビットのグループ、AEAD 暗号、そして現代的な署名の証明書です。その変更を機器の所有者に求め、交渉されたバージョンと暗号をクライアントのログで確認してください。例外はホスト、ゲートウェイ、交渉されたプロトコル、承認者、失効日とともに記録します。その記録こそが、一時的な回避策を既定にしないようにします。