モダンなcipher suiteに対応していないHTTPSクライアントを搭載したロードバランサが存在する問題について

実は一般的に知られている問題なのかもしれないものの,最近知ったのでメモ.

概要

  • 一部のロードバランサアプライアンスにおいて,搭載されているHTTPSクライアントが所謂"モダンな"暗号スイートに対応していないものが存在する
  • このため,特定条件下において意図せずヘルスチェックに失敗し,場合によってはVIPがdownする
  • 現時点では直ぐに影響が出る訳では無いものの,気に留めておかないと近い将来痛い目を見そう

背景

DSR構成のロードバランサでSSL(TLS)を使用する場合,SSLの終端はロードバランサではなくリアルサーバの仕事になる*1

この環境下においてリアルサーバの死活監視にLayer 7方式を使用するパターンを考える.このパターンでは,ロードバランサからリアルサーバにSSLで接続し,HTTP GETないしHEADリクエストを投げて意図したレスポンスが返ってくれば,リアルサーバは正常動作しているとみなされる*2

f:id:yunazuno:20150227225611p:plain

問題となるケース

リアルサーバ上で稼働しているWebサーバ(Apache, Nginx等)において,セキュリティの要件上Mozillaが言うところの所謂"モダンな"cipher suiteのみ使用可能にする (=RC4や3DESに依存したCipher suiteを使用不可にする) ケースを考える.

この時,ロードバランサがヘルスチェックに使用するHTTPS Clientが先に述べたモダンなcipher suiteに非対応だと,リアルサーバとのHandshakeに失敗してしまう.その結果,実際は正常動作しているリアルサーバが死んでいると誤認識されてしまい,意図せずリアルサーバないしVIPがdownする.

どう対応するか

ぱっと思い付く対応策はこんな感じ:

  1. Layer 7ヘルスチェックを諦めてLayer 4ないしLayer 3でのヘルスチェックに切り替える
  2. 要件を曲げてCipher suiteの制約を緩める
  3. ロードバランサ側をモダンなCipher suiteに対応させる
    • ベンダに機能追加してもらう,対応OSにバージョンアップする,対応LBに入れ替える,など

商用サービスでモダンもの限定にするケースはまだレアだとは思うものの,気に留めておく必要がありそう.特に,現在使用しているCipher suiteがある時点から安全でなくなる可能性を考慮すると,上述したケースでどういう対応を取るか,ぐらいは考えておいたほうが良さそう.

また,今回のHTTPS Client側cipher suiteの問題に限らず,ロードバランサでSSLを終端した場合のCipher suiteやTLSバージョンの対応状況等,ロードバランサ+SSLには諸々のハマりどころが存在するようなので,運用している人は頑張りましょう.

*1:一般的なプロキシ構成下では,SSLはロードバランサで終端する

*2:プロキシ構成下では,リアルサーバへの接続にSSLは不要