以前、お客さん先であるセキュリティアプライアンスの検証作業に立ち合う機会がありました。といっても、その場でいろいろとチューニングを行なう、というよりは、実環境にインラインでアプライアンスをいれて、モニタリングのみさせておき、どんな攻撃がきているかをあとで確認する、というだけではありましたが。
その製品が優れているのは、「アプライアンスにサーバと同じのキーペア情報を持たせておけば、クライアント⇔サーバ間で行なっているSSL通信の中身も見れて、それをモニタリングすることができる」という点です。アプライアンス自身がSSLオフロード（SSLアクセラレータ）の機能を持っていて、アプライアンスとサーバとの間は暗号化されていない平文で通信するのならば話はわかるのですが、クライアント⇔サーバ間で暗号化していて、途中にある機器が通信に影響を与えずに中身だけ見れてしまう、というのはあまりないかもしれません。
まあ、普通に考えるとそれができてしまったらSSLの意味が全くないのですが、あくまで「秘密鍵を知っていてもいい（セキュリティポリシー上問題ない）アプライアンスにはいっている」という前提なので構わないのかな・・・。
確かに、http://www.itservice-a.com/about_ssl/ などに紹介されているとおり、秘密鍵さえあればクライアント-サーバ間でデータ通信に使うための共通鍵を生成する際に流れるパケットもすべて見えるので、クライアント-サーバと同じ共通鍵をセキュリティアプライアンスでも保持できるので、原理的には通信が傍受できそうな感じです。
とりあえずお客さん先に機器を設置し、監視を続けていました。平文の通信に関してはもちろん問題なく解釈できるのですが、解読できるはずのSSL通信が一部解読できません。え？なんで？仕方ないので、今回はお客さんには平文のみのレポートを提出することになりました。
SSL通信が解読できなかった理由をサポートに聞いたところ「共通鍵のアルゴリズムがDHベースだから」だそうです。。。なるほど、言われてみるとなんとなくわかったぞ・・・。まあ、だとすると、他の方法としては、セキュリティアプライアンスに頼るのではなくサーバ側で同等のセキュリティ機能をもったソフトをインストールするか、あるいはクライアント⇔サーバの間にSSLアクセラレータ（今どきはSSLアクセラレータ専用機も数少ないのでおそらくはSSLアクセラレータ機能をもったロードバランサをかわりにいれる）をいれてそこれ暗号化/復号化を行ない、セキュリティアプライアンスはSSLアクセラレータの内側において平文が読める形にしておく、という方法になるでしょうか。まあ、やりようはありますよね。
でもなんでDHベースのアルゴリズム使ってるんだ？RSAのほうが多いんじゃないのかな・・・。と思って調べてみました。
まず前提ですが、SSL通信を行なう際、最初のネゴシエーションの部分では、
- データ通信時に使用する共通鍵を安全に共有するためのアルゴリズム
- 相手を認証するためのアルゴリズム
- データ通信を暗号化行なうための共通鍵のアルゴリズム
- メッセージ認証（改ざん防止）のアルゴリズム
の情報がやりとりされ、クライアント-サーバ間で両者が使えるうち最も強力と思われるアルゴリズムが採用されます。
それらのアルゴリズムに基づいて計算された共通鍵などが実際のデータ通信で使われます。よく使われているのはそれぞれ
- RSA、DHなど
- RSA、DSAなど
- DES、3DES、RC4など
- SHA1、MD5など
です。
DHアルゴリズム・・・http://ascii-business.com/vpn/vpn5-5.html http://scientia.jpn.org/index.php?%A5%B3%A5%F3%A5%D4%A5%E5%A1%BC%A5%BF%B9%D6%BA%C2%2FDiffie-Hellman%B8%B0%B8%F2%B4%B9%A5%A2%A5%EB%A5%B4%A5%EA%A5%BA%A5%E0 などにもあるとおり、クライアント⇔サーバ間で共通鍵を作る際、お互いに共通する（ネットワーク上に流してもいい）情報と、自分だけが持っている（ネットワーク上に流れない）乱数情報とがあり、クライアント⇔サーバ間は共通情報と自身の乱数情報のみ（相手に自分の乱数情報を教えることなく）で両社の共通鍵が共通でき、それ以外の盗聴者は共通鍵を生成することが（現実的な時間では）できない、ということです。
昔から知られている理論で、証明自体は数学が必要になりますが、感覚的に考えても、「これだと確かに、クライアント⇔サーバ間でやりとりされている鍵交換の際に使用する公開鍵/秘密鍵は通信毎に一時的に作成するものなので、公開鍵を含む証明書と（証明書と対になる）秘密鍵をセキュリティアプライアンスに持たせたところで、通信を傍受できず、プリマスターシークレットを作成できない」ということはわかります。
じゃあ、話を戻して、なんでDHベースのアルゴリズムなのかな？もしかして、一部の古い端末などで、ＲＳＡに対応していないものがあるのかな？
でも、いろいろ調べてみるとそうではないようです。おそらくはOpenSSLのサーバや、OperaやFirefoxなどのブラウザが、鍵交換方式としてDHベースのもの（DHEやECDHEなど）を優先して選択するからのようです。
（Internet Explorerの場合にはRSAのほうを優先するため、ネゴシエーションの結果、RSAを使うことになるようです）
いつだかのOpenSSLでは、暗号化方式として”DHE-RSA-AES256-SHA”（鍵交換をDHE、認証をRSA、共通鍵を256ビットAES、ハッシュをSHA1で行なう）を標準としているようです。確かにこれだと強力そうですね。もちろん、今であれば2010年暗号化問題の関係でSHA2を使うべき、という話はありますが。
上記とも関連しますが、DHE-RSAを優先しているのは、おそらくは「DHベースで鍵交換を行なえば、秘密鍵が漏れた場合でも盗んだ相手にデータの複合をされることはない。この点においてはRSAよりも優れている。しかし、DHだけでは、Man-in-the-middle攻撃に対して脆弱なので、認証をRSAにすることにより、相手が正当であることを確認する必要がある」
ということかと思われます。
ちなみに、「クライアント⇔サーバの両者が使えるもっとも強力なアルゴリズムの組み合わせをネゴシエーションによって決定する」というのがSSLの前提ですが、それ自体も実際の挙動とは違うようです。
たとえば、ApacheにモジュールでSSLを載せる場合、デフォルトではクライアントが提示した順番で一番上にある暗号スイートを使用します。で、Internet Explorer（WindowsXPのIE（確か7））ではRSAを鍵交換アルゴリズムに使い、どういうわけか共通鍵の鍵長も短い（128ビット）のようです。OperaやFirefoxでは上記のとおりDHベースのアルゴリズムが使われます。
これをクライアントのデフォルトを受け入れるのではなく、サーバ側で提示する方法を優先させたい場合には、httpd-ssl.confのパラメータ設定を行なえばよいようです。
（参考サイト
http://info.isl.ntt.co.jp/crypt/camellia/dl/sslserverconstructionguidev2.1_090319.pdf
http://support.citrix.com/article/CTX118701
http://d.hatena.ne.jp/nahate/20080801
http://www.drk7.jp/MT/archives/001025.html
http://slashdot.jp/comments.pl?sid=337315&cid=1042181 ）
この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)
