このページの本文へ

前へ 1 2 次へ

Googleの狙いと背景を分析する

GoogleからOpenSSL派生版「BoringSSL」登場

2014年06月27日 11時00分更新

文● 鈴木淳也(Junya Suzuki)

  • この記事をはてなブックマークに追加
  • 本文印刷

 「OpenSSL」といえば、マシン間のセキュアなネットワーク通信を実現するプロトコル「SSL/TLS」をオープンソースで実装すべく記述されたライブラリ・ソフトウェアのことだ。プロジェクトは1998年からスタートし、その後も改良を続けて現在に至っている。

 OpenSSLの利用範囲の広さと重要性は、皮肉にも2014年4月に存在が報告された「Heartbleed」という致命的な脆弱性によって改めてクローズアップされることになった。

 一説によれば、インターネット上に存在するセキュアな接続機能を持つWebサーバの17%、数にしておよそ50万台がHeartbleedの影響を受ける可能性があったという。その後対応パッチが提供されたものの、現在もなお問題を抱えたままのサーバが存在し続けているとみられている。

 こうした中、OpenSSLの派生バージョンにあたる“フォーク(Fork)”が次々と誕生して話題になっている。ひとつはOpenBSDプロジェクトの「LibReSSL」で、Heartbleedの問題が明らかにされた2週間後にはすでにOpenSSLソースのうち9万行を削除した“軽量版”にあたるLibReSSLのコードを公開している。そしてつい先日登場したのがGoogleの「BoringSSL」で、LibReSSL同様にOpenSSLの新しい可能性を探ろうとしている。結果、SSL/TLSのオープンソース・ライブラリは3つに分家する形となったわけだが、今回はその背景と影響を考えてみる。

OpenSSLサイト

「Heartbleed」問題の概要とその後をおさらい

 「Heartbleed」(心臓からの出血)問題の経緯を少し振り返ってみよう。OpenSSLそのものは10年選手のプロジェクトであり、長らく多くの製品で利用され続けてきた。

Heartbleedサイト

 問題の発端となったのは2012年2月にRFC6520としても登録された「Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension」(通称「Heartbeat Extension」)で、TLSのセキュアコネクションが維持されているか(Keep Alive)を再接続手続きなしにシンプルに行なう方法として、文字通り「Heartbeat」(心拍)を測るための拡張が提案された。

 2011年にはRFC6520の著者のひとりでもあるRobin Seggelmann氏の指示でOpenSSLへのHeartbeat Extensionが施され、同年末には問題となるコードの登録が行われ、2012年3月のOpenSSL 1.0.1リリースとともに全世界へと拡散することとなった。

 Heartbleedの問題の根本は、いわゆる「バウンダリ・チェック」(Boundary Checking)と呼ばれるリクエストに対する領域の正常性チェックが行なわれていない点にある。Heartbeat Extensionでは、クライアント側のリクエストに応じてサーバ側が応答する仕組みが採用されているが、通常であれば必要最低限のバイト数のデータをサーバ側に要求して返答を受けるのに対し、本来であれば受けられないはずのサイズのバイト数のデータをサーバに要求することで(最大2の16乗バイトで64KBを指定可能)、必要以上のデータが取得できてしまうというものだ。より具体的には、本来のTLSコネクションで得られるべきデータだけでなく、同サーバを通じて行われた他の通信のデータも入手できてしまう。

 Heartbleedの脆弱性では、サーバの特定のデータ領域を狙い打ちしてデータを入手することはできないものの、同サーバへのアクセスを通じて行なわれた秘密通信であっても脆弱性を利用してメモリ上に残っている非暗号化データを無差別に入手可能で、これを利用することで個人情報やクレジットカード番号、パスワードなど秘密の情報を抜き取られる可能性がある。つまり、使い方によってはTLSの通信を丸裸に近い状態にもできる。

 発見から対策までの経緯はMark J Cox氏の記述が詳しい。手順的には問題が発見された4月1日から、多くのプラットフォーム向けのOpenSSLソフトウェアの対策が完了した4月7日時点で公表に踏み切った形だ。Heartbleedの詳細や影響範囲は同名を冠したサイトでも紹介されているが、SSL/TLSはいわゆるセキュアなWeb接続(HTTPS)だけでなく、VPNやチャットクライアントをはじめ、およそインターネットのセキュアな通信のほとんどに何らかの形で利用されている。ゆえに影響範囲が甚大というわけだ。

 4月の一連の騒動が過ぎたタイミングで、各方面からはHeartbleedの影響に対する評価と、その原因や今後の対策が議論されるようになった。この中で改めて指摘されたのが、「Web全体の3分の2に何らかの影響を与える可能性がある」とも大騒ぎされるほどの問題にもかかわらず、その対策はごく小数の専門家の活動に依存しているという偏りだ。

 SSH Communications SecurityのJohn Walsh氏が投稿した「Free Can Make You Bleed」というブログエントリのタイトルがすべてを物語っているが、これだけ活用されているソフトウェアにもかかわらずOpenSSLにかかわっているフルタイムのエンジニアは実質最大で2人という、大人気のフリーソフトウェアを支える裏側で起きている根本的な問題が明らかになった。OpenSSLプロジェクトについても、年間予算が1億ドル未満でほとんどを寄付に頼っており、人員も含めてリソース不足が深刻な状況にあるという。

 今回問題の発端となったSeggelmann氏も自己反省の中で「十分なチェックを行なうための人員がいなかった」ことを認めており、プロジェクト運営の難しさを浮き彫りにしている。

前へ 1 2 次へ

カテゴリートップへ

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン