HTTPSだけでは不十分だ。ウェブ・トラフィックをより安全にするための対策とは
オープンソース・セキュリティー・ソフトウェアOpenSSLの致命的な欠陥「Heartbleed」によって、ウェブ全体のほぼ3分の2が悪意ある攻撃の危険に晒された。おかげでインターネット・ユーザー達は、自分のパスワードを変更し、そのオンライン・アカウントがハッキング被害にあっていないかどうかの確認に追われている。
特に、認証用のプライベート・キーをサーバーから奪うことは不可能だと考えられていたため、Heartbleedは多数のウェブサイトにセキュリティの悪夢を引き起こした。Heartbleedが発覚して6時間もたたないうちに、カナダでは900人を超える人々の納税情報がハッカーに盗まれてしまったのだ。
この最悪の状況にも希望の光は存在する。「Perfect forward secrecy」と呼ばれる暗号化ソフトを採用するウェブサイトでは、ハッカーがたとえそのサーバーのプライベート・キーを手に入れたとしても、ユーザーのデータを過去に遡って解読することはできないのだ。
HTTPSの問題点
まず、セキュアなウェブサイトとの通信時に、ユーザーのデータを保護してくれるHTTPSについて詳しく知ろう。
ユーザーが従来のHTTPS暗号化を使用したセキュアなウェブサイト上にいるとき、ユーザー名やパスワードといった個人情報の通信は、ハッカーやNSA（米国国家安全保障局）による傍受や解読の危険から守られているはずだ。OpenSSLは、ブラウザとサーバ間で送受信されるデータを保護し、ウェブサイトとの安全な接続を可能にしてくれる。
通常、安全な接続が作成される場合、ウェブサイトはブラウザとの間にマスター・キーを生成する。このマスター・キーは特定のユーザーのものだけでなく、何百万ものセッションを暗号化するために使用される。プライベート・キーの所有者だけがセッション・キーを「解除」できるため、ユーザーの情報はすべて安全だ。しかしHeartbleedバグを悪用すると、攻撃者はウェブサイトのプライベート・キーにアクセスし、次にユーザーのセッション・キーで保護された情報を解読することができてしまう。
それだけではない。Heartbleedによって露出してしまったプライベート・キーを利用すれば、HTTPSサーバーから記録されたデータを過去に遡って解読することができてしまうのだ。そのため、もし特定のウェブサイトのトラフィックをずっと記録し続けていたハッカーがいた場合、彼らはHeartbleedのおかげでそのサイト用のプライベート・キーにアクセスできてしまうのである。
Forward Secrecyの意義
これで、HTTPSだけではHeartbleedを止められない理由が分かった。ではウェブサイトの取るべき手段とは何だろうか？
Perfect forward secrecyは、たとえ誰かがサーバーのプライベート・キーを手に入れたとしても、ユーザーの個人的な情報記録を過去に遡って「解読する」ことを妨ぐ暗号化技術だ。Perfect forward secrecyの場合、1つのマスター・キーに依存する代わりに、セキュアなウェブサイトにアクセスするごとに一時的なセッション・キーが生成される。つまり、鍵が生まれては消える「短期的な暗号化（ephemeral encryption）」が行われるため、HTTPSのようにハッカーがデータを解読することができないのだ。
「Forward secrecyでは、クライアントとサーバーがセッション・キーを照合する方法が異なります」とF-Secureのシニア・リサーチャーであるティモ・ヒルボネンは語っている。「最大の特徴は、解読にはセッション毎に専用の鍵が使われ、その鍵は一時的なものだという点です」
セキュリティーをメッセージ・アプリに例えるなら、forward secrecyはSnapchatに似ている。一旦セッションが終了すると、そのキーは消えてしまう。Forward secrecyを採用するウェブサイトは、ハッカーが過去に盗み取った情報を解読することを許さない。
しかし、ユーザーが心配しなければならないのはソフトウェアの脆弱性だけではない。エドワード・スノーデンによって公表されたドキュメントによれば、NSA（米国国家安全保障局）はいずれ解読するつもりで大量の暗号化されたデータを常時記録しているという。ユーザーにとって幸運なことに、forward secrecyを利用すればそのNSAでさえ国民の電子メールを読み取ることはできないのだ。こういった事実によって、大手企業は現在自社の暗号化ポリシーを見直すようになってきている（NSAはHeartbleedを前から認識していたと言われているが、同局はこれを断固として否定している）。
誰がForward secrecyを使用しているのか？
Forward secrecyは20年以上前から存在しているが、ほとんどのウェブサイトはまだそれを実装していない。SSL Labsによると、最もポピュラーなウェブサイトでも半分以上はforward secrecyを使っておらず、なんらかの形で採用しているサイトはまだ42％程度という状態だ。
Googleは以前よりユーザーの情報保護に関するパイオニアであり、2011年11月にforward secrecyの採用を義務付けている。同社はその後OpenSSLでの実績を公表し、他社にも追従するよう呼びかけている。
しかし残念ながら、他の大手IT企業がそれに追いつくのにはさらに2年ほどかかってしまった。
2013年の中旬から後半にかけて、フェイスブックとマイクロソフト、ツイッターはセキュリティーを拡充し、forward secrecyを取り入れ始めている。先日（Heartbleedが公表される一週間ほど前）ヤフーも、自社のサーバーにforward secrecyを採用する意向を表明した。しかし間に合わなかったのか、Yahoo MailはHeartbleedの深刻な影響を受けてしまった。
ヒルボネンによると、ウェブサイトがforward secercyを採用しない主な理由の1つは、パフォーマンスであるという。Forward secrecyはCPUリソースを多く必要とする。サーバーを人間に例えるとすれば、forward secrecyはHTTPS暗号に比べて「頭を使う」作業なのだ。
ネットワーク・デザイナーのビンセント・ベルナットによれば、これまでのHTTPSセキュリティーに比べて、forward secrecyは30%以上も多くCPUを使うという。
「設定するのはそれほど難しくありません」とヒルボネンは語っている。「それよりもCPUリソース、ハードウェア要件、パフォーマンスへの影響が問題なのです」
さらに、forward secrecyを導入するためには、ウェブサイトの暗号化に関する知識を持った人材が必要となる。実装するにはまず、forward secrecyを優先するようにサーバーを設定する必要があり、最も普及している暗号化アルゴリズムを2つ用意しなければならない。Help Net Securityというサイトでチュートリアルが提供されている。
Heartbleedによって我々は、インターネット上の安全であるはずのデータは、思っていたほど安全ではないことを改めて思い知らされることになった。また、Heartbleedが引き起こした混乱が落ち着くまでにはまだしばらく時間がかかるかもしれない。
しかし、ユーザーの保護を強化するための単純だが意義のある対策も存在しており、大手IT企業各社は先陣を切って対応を進めている。Heartbleedをきっかけとして、より多くのウェブサイトがforward securityを採用し、ウェブと我々のデータを安全に保護してくれることを願いたい。
画像提供：Alonis（Flickr より）
※本記事はReadWrite Japanからの転載です。転載元はこちら。
