SSL/TLS可視化ソリューションの背景
2013年、スノーデン氏がカミングアウトした『国家レベルによるインターネット大規模盗聴』を契機に、常時 SSL/TLS 化の必要性が叫ばれる時代になりました。
今や正規の SSL/TLS 用のサーバ証明書を作成するコストは極端に小さくなり、常時 SSL/TLS 化はしっかりと根付き、盗聴によるリスクも小さくなりました。
しかし暗号化されていることが逆に、ウィルスや不正通信の温床となってきました。SSL/TLS 暗号化では通信しているクライアントとサーバ以外に通信の中身が見れませんので、NW機器(ことさら UTM)によるアンチウィルスや IPS、URL フィルタといった制御が十分にできないためです。
そのため、UTM においては SSL/TLS を復号化してパケットの中身を検査する『SSL インスペクション』という機能が実装され始めました。
参考:UTM と SSL インスペクション
しかし、IPS や URL フィルタといったセキュリティ検査をするだけでもスループットに影響があるのに、その上 SSL/TLS の復号化/暗号化まで実施させるとパフォーマンスに懸念が出てきます。スループットを保ったまま、全てのことを 1 つの機器で担うには限界がきているのです。
そこで登場したのが SSL 可視化ソリューションです。SSL 復号化/インターセプトとも呼ばれます。SSL/TLS の復号化/暗号化処理をハードウェア (ASIC) 処理を行える専用機器にオフロードするのです。
なお、SSL というのは NetScape 社が開発した独自プロトコルで、セキュリティ上の問題により使われてはいけない技術です。一般にはその後継であり RFC により規格化された TLS が使われますが、名残でソリューション名などにはよく "SSL" という単語が使われます。(SSL-VPN、SSL 証明書、SSL インスペクション、OpenSSL 等)
以降では『用語としての SSL』は別として、SSL/TLS の表現を TLS に統一したいと思います。
SSL 可視化 (インターセプト) の仕組み
SSL 可視化は主に https のみを対象とすることが多いです。仕組みとしては単純で、復号および再暗号化を行う機器をインターネットとの http 通信経路上に配置し、その間にアンチウィルスや IPS、URL フィルタを行う機器 (UTM等) を配置するだけです。
構成例を以下に示します。
例にある通り、https://www.yahoo.co.jp への通信の中身をチェックしたい場合はまずクライアント PC の https 通信をジャックし、クライアントと TLS 復号装置間で TCP コネクションおよび TLS セッションを確立します。
そして TLS 復号装置からは http に変換した上で www.yahoo.co.jp のサーバ目指して向かい、途中の UTM 等の検査装置で中身をチェックされますが、その後の経路上に TLS 暗号化装置が待ち構えており、ここで再び通信ジャックを行い、http の中身を https に変換して www.yahoo.co.jp と通信します。一般には復号装置と暗号化装置は同一機種です。
ここで 1 つ問題となるのが、TLS ネゴシエーションの中で TLS 復号装置がクライアント PC に提示するサーバ証明書についてです。
TLS ネゴシエーションの中で証明書の正当性を主張するために秘密鍵による認証を行っています。ですが www.yahoo.co.jp の秘密鍵は当然手に入らないので、ここでは偽物の証明書を使うしかありません。
TLS 復号装置ではクライアントの ClientHello にある SNI (Server Name Indication) の情報を使って動的にサーバ証明書を生成します。例えば PaloAlto が『SSL decryption』ポリシーによって復号化を行う際は、PaloAlto 自体が www.yahoo.co.jp のサーバ証明書を生成します。(そのために PaloAlto がルート CA となり動作します。)
一方、クライアントによる一般的なサーバ証明書の正当性の確認方法は、そのサーバ証明書の発行者を示す「ルート証明書」がそのクライアント PC に「信頼されたルート証明機関」としてインストールされているかを確認することです。
なので TLS 復号装置で動的に生成されるサーバ証明書のルート証明書 (先ほどの例だと PaloAlto の CA のルート証明書) を、全てのクライアント PC に「信頼されたルート証明機関」としてインストールしておく必要があります。
参考:ルート証明書のインストール状態確認方法やインストール方法
コメント