データが漏れないためのSSL

SSLを導入すれば、セキュリティーが確保できるという認識は誤っています。SSL通信は、平文での通信に比べて余分な計算機能力を使用するので、本当に必要なとき以外は使用しないことが多いのが現実です。システムはデータの重要性を判断することができないので、SSLが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならないのです。

SSLは公開鍵証明書を用いて認証をし、なりすましを極力排除しようとします。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではありません。
電子証明書には認証局による電子署名が与えられます。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的にはルート証明書と呼ばれる一群の証明書に行きつきます。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持しているのです。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められます。これらが保証されない認証局のルート証明書を組み込むことは、SSLにおける認証機能を破綻させることになる。例え認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意する必要があります。

Debianは2008年5月15日脆弱性に関する報告[8]を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536通りの予測可能な物が生成されてしまった事を明らかにしました（なお、この問題はOpenSSLそのものの脆弱性ではない）。安定バージョンがリリースされた2007年4月8日以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、SSH鍵、OpenVPN鍵、DNSSEC鍵、X.509証明書を生成するのに使われる鍵データ、およびSSL/TLSコネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てをブルートフォースアタックで試すだけでいずれの鍵が使われているか解読可能であり(SSHでは20分間で解読できたと報告されている)、また脆弱な鍵がインストールされたDebianを含むの全てのオペレーティングスシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけています(その対象にはMicrosoftWindowsなど非UNIX系OSも含む)。具体的対応については、Debianの報告の他、JPCERT/CCの勧告[10]等に従うべきです。