古いピア一台が TLS 1.0 を強制する——例外を限定し、ホスト全体を弱めない

古い端末が一台現れて接続に失敗すると、いちばん手早く見える修理は、接続が通るまでホスト全体を弱めることですが、その取引はその瞬間には見えず、実際には恒久的なものになります。ようやく通った下限を誰も撤去しないからです。圧力を生む故障は大きく二種類あり、そのうち片方だけが暗号スイートの話です。まず故障を仕分けし、それから例外を、広がりようのない場所に置いてください。

ディレクティブを書き換える前に、故障を二つに分ける

共有暗号がない、あるいは未対応のプロトコルバージョンだというサーバーのログ行は、制御チャネルからのもので、両端がネゴシエーション自体をどう守るかで合意できなかったことを意味します。サーバー証明書の検証方式が有効になっていない、というクライアントの行はまったく別の場所から来ており、そのクライアントは誰が応答したかをそもそも確認していません。データ暗号を変えても二番目の事例には効かず、ロール検査を足しても一番目の事例には効きません。

最後の行はたいてい結果にすぎないため、切断前の最後の行ではなく、両側それぞれの最初の失敗行を取ってください。次に、クライアントが実際に開いたファイルを突き止めますが、インポートしたプロファイルは表示名違いで二重に存在することが多く、誰も読まないほうのコピーを編集すると、説得力のある「変化なし」が出来上がります。実行中のプロセスは起動時の設定を保持するので、保存したファイルは読み込まれたファイルではありません。以下のコマンドは、同じ試行についてクライアント側のネゴシエーションとサーバー側の見え方を並べて示します。

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

弱い下限は、二つ目のリスナーに置くのが誠実

端末がデータチャネル 2.5 以前で TLS 1.0 どまりの場合、サーバーは制御チャネルの下限を下げ、古いクライアントが認識するデータ暗号を提供する必要があります。フォールバックのディレクティブはまさにそのピアのためにあり、暗号リストは現代のクライアントを現代のスイートにつなぎ止めます。どちらのディレクティブもユーザーや接続ではなくリスナーに属し、後からクライアント単位のオプションで狭めることはできません。だからこそ、メインポート上の旧式端末一台は、そのポートを共有するすべてのピアについての判断になります。

プラットフォームが許すなら、旧式リスナーを別ポートの独立したインスタンスとして動かし、そのポートは端末のアドレスからのみ許可し、メインサービスには手を付けず、二つ目のリスナーがなぜ存在するのかを、その設定が入っているファイルに書き残してください。そうしないと、将来の整理作業がそれを残骸と読み取ります。弱い下限が端末のところで終わるのでなければ、この分割には意味がありません。

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

古いプロバイダ証明書が実際に壊すもの

検証エラーの正体はロールの結び付けの欠落であり、これがないとクライアントは、信頼された CA につながる証明書なら、それがサーバー向けに発行されたかどうかに関係なく受け入れます。まず証明書をサーバーのロールに結び付け、その結び付けを調整用のつまみではなく要件として扱ってください。その手順の後もまだ失敗するプロファイルだけが、本当の証明書問題を抱えています。

鍵長や署名アルゴリズムが OpenSSL の既定ポリシーを満たさなくなった古いプロバイダ証明書は、制御チャネルでセキュリティレベルを限定的に変えるべきケースであり、そこでレベルを下げても検証は無効にならず、空の CA、検証の無効化、ホスト名の未確認と組み合わせては決してなりません。その行は必要とする一つのプロファイルの中に留めてください。緩めた OpenSSL 設定を全体にエクスポートすると、同じ緩さをマシン上のすべてのプログラムに渡すことになります。

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

バナーではなく、ネゴシエートされた値を読む

verbosity 4 では、両端が合意した制御チャネルの TLS バージョンと暗号、そしてセッションのデータ暗号を出力します。バナーが報じるのは成功であってその条件ではないため、初期化バナーではなく、その行を読んでください。次に、現代的なクライアントをメインリスナーに再接続し、共有設定に漏れ出した例外がまずここに現れるので、依然として現代的なスイートに着地することを確認してください。書き出した値は次のレビューの基準になります。

古い端末を単独で試したとき、それは接続でき、ログの中で弱いパラメータを示す唯一のセッションであるべきです。二台目のピアも古いスイートをネゴシエートするなら、例外は意図より広く、リスナーの分割は実際には起きていません。結論だけでなく、両方の観察を記録してください。

すべての例外には所有者と期限が要る

撤去条件のない例外は静かに既定値になるので、端末、所有者、理由、そしてそれが消える日付を、正当化する設定の隣に置いてください。その一行がなければ、弱い下限はそれを必要としたハードウェアより長生きします。

目指すべき結果は、クライアントの交換か、プロバイダに現行プロファイルを求めることであり、例外は設計ではなく遅延です。端末を退役させるときは、リスナーとプロファイルを同じ変更で削除し、どちらかの半分が動き続けないようにしてください。これらは古いパラメータを安全にするものではなく、一台の端末の限界が全員の基準になるのを防ぐだけです。