3分でわかるHeartbleed問題とSSL Heartbeat
この記事は2014年4月14日に作成されました。 |
まずは、事実から。
グローバルナレッジのWebサイトはOpenSSLのぜい弱性の影響を受けません。理由は単純で、OpenSSLを使っていないからです。
という前置きを踏まえ、ここでは、今世間を騒がせているHeartbleed問題について簡単に技術解説しておきます。
そもそもSSL Heartbeatとは何か?
今回のぜい弱性は、比較的新しい(2011年12月頃、OpenSSLに導入された拡張機能)規格である「Heartbeat」のバグによるものです。Heartbeat(心臓の鼓動)のバグなのでHeartbleed(心臓出血)と呼ばれたようです。
そもそも「SSL Heartbeatとは何か」ということはほとんど報道されていないようですが、どうやらkeep-alive、つまり、データの送受信がなくても定期的にデータを送ることで通信セッションを維持する機能のようです。
なぜこのバグは発生したのか?
上記のように指摘する人もいるようです。
日本語による解説は、ブログ「本の虫」の「なぜTheo de RaadtはIETFに激怒しているのか」に詳しく記載されています。
バグ自体は非常に単純なもので、C言語にありがちなミスです。こちらも日本語のブログだと「THE FIRST CRY OF ATOM」の「Heart Bleedを読んだ」に詳しく記載されていました。
オープンソースソフトウェアの良いところは、「多くの目玉」つまり、テスターが世界中にたくさんいて、迅速なフィードバックが得られる点です。しかし、職業的なテスターではないため、自分が使う機能しか使って(テストして)くれないという欠点もあります。
先のブログで「IETFに激怒」というのは、誰も使わない機能を標準にしてしまったことに対する怒りです。
なぜこのバグが深刻化しているのか?
ソフトウェアにバグはつきものですから、バグがあったこと自体は非難できません。もちろん、バグを最小限に抑える努力はすべきですが、一定以上の規模のソフトウェアでゼロバグは事実上不可能です。
それより、バグが出たときの対応体制や、継続的な検査態勢を重視すべきです。オープンソースにも、もちろんこうした体制はあるわけですが、やはり使われていない機能に対する対応は難しいようです。
「SSL Heartbleed」対応策
SSL Heartbleedの対応策は、以下の通りとされています。
- Webサイト側で、SSLのぜい弱性を修正
- Webサイト側で、新しい証明書を取得
- ユーザーがパスワード変更
Webサイトで対応する前にパスワード変更をしても無意味ですのでご注意ください。
また、「対応したのでパスワードを変更しろ」という偽メールが出回っているようです。偽サイトでパスワードを入力すると、新しいパスワードがそのまま盗まれてしまいます。こちらの方が被害を受ける可能性は高そうですので、メールで来たパスワード変更依頼には十分注意してください。少なくともSSLで暗号化されていないサイトに接続すべきではありません。