Latest topics > Firefox 3で安全にアドオンを配布するための方法のまとめ

Firefox 3で安全にアドオンを配布するための方法のまとめ - Dec 25, 2007

第8回Mozilla拡張機能勉強会のプレゼン資料を公開した。

以下、内容を改めて整理してみる。

update.rdfの確実性の保証

まず、Firefox 3ではセキュアな方法で自動更新が行われないアドオンはインストールできなくなる。ここでいう「セキュアな自動更新」とは、「インストールされたアドオンについて、自動更新でダウンロードしてきた新バージョンのXPIパッケージが、そのアドオンの作者が提供した物であると確実に保証できる」ということを指している。

その挙動を実現するために、Firefox 3ではアドオンのマニフェストファイルの解析時に、以下の判別が行われる。

1. そのアドオンの自動更新のための情報（以下、update.rdf）がSSLを使って提供されているか？（update.rdfのURIのスキーマ部分が「https」であるか？）　また、その場合、それはオレオレ証明書ではなく、ベリサインなどのきちんとした認証機関によって証明された物であるか？
2. SSLを使ったものでない場合、取得したupdate.rdfの署名を検証するための公開鍵は含まれているか？

Firefoxのアドオンのupdate.rdfはXML形式のリソースとして提供される。そのupdate.rdfの中に、新しいバージョンのアドオンのXPIインストーラのダウンロードURIが記述されている。ということは、このupdate.rdfが通信経路上で改竄される可能性がある――他人が別のリソースを「これがupdate.rdfですよ」と偽って、アドオン作者になりすまして送信できる――場合、最悪のケースでは、「本来の作者が作ったものではない、悪意あるコードが含まれた偽物のインストーラ」を掴まされてしまう恐れがある。よって、上記のどちらかの条件に適合しない場合、そのアドオンのインストールはFirefox 3によって拒否されるようになる。

1の場合はSSLで通信するからまぁ安全、ということでとりあえず説明は省略する（SSLだけじゃ安全じゃねえよとツッコみたい人はいるかもしれないけど）。

2の場合、update.rdfはXML署名という技術によって署名が施されることになる。簡単に言うと、update.rdfの内容そのものと、アドオン作者のみが持つ秘密鍵（という名前の数字）を元にして、暗号化された文字列が生成され、それがupdate.rdfに埋め込まれる。この「埋め込まれた文字列」が「署名」となる。この「署名」は、アドオンのinstall.rdfに書き込まれた公開鍵（という名前の数字）を使えば暗号化される前の状態に戻すことができるので、それをupdate.rdfの内容と比較して一致すれば、そのupdate.rdfは確かに元のアドオン作者が作ったままの内容から少しも改竄されていないし、そのupdate.rdfは確かに元のアドオン作者でなければ作ることができない、ということが保証できる。

ダウンロードした新バージョンのXPIの確実性の保証

さて、こうして取得した「確かにアドオン作者自身が提供した通りの内容である」ことが保証されたupdate.rdfであるが、このリソースには新バージョンのアドオンのXPIファイルをダウンロードするためのURIの情報しか含まれていない。そこでさらにそのファイルをダウンロードする作業があるわけだけれども、ここでまたもう一度チェックが入る。

1. そのXPIインストーラはSSLを使って提供されているか？（ダウンロード用URIのスキーマ部分が「https」であるか？）　また、その場合、それはオレオレ証明書ではなく、ベリサインなどのきちんとした認証機関によって証明された物であるか？
2. SSLを使ったものでない場合、ダウンロードしたXPIインストーラを検証するためのハッシュがupdate.rdfに含まれているか？

1の場合は前項同様省略する。

2の場合、アドオン作者はまず、新バージョンのXPIインストーラのファイルの内容を要約した一意な文字列を生成する。これを「ハッシュ」と言って、SHA1やSHA512などアルゴリズムは何種類かあるんだけれども、統計的手法によって「似た内容のファイルからは同じハッシュは生成されない」ように考えられている。update.rdfにはそのハッシュが書き込まれていて、実際にダウンロードされたファイルの内容を元にFirefoxがハッシュを計算して、「実際のファイルのハッシュ」とupdate.rdfに書き込まれていた「ダウンロードされるべきファイルのハッシュ」とが等しければ、ダウンロードしたファイルは確かに元のアドオン作者が作成した物であるということが保証できる。

McCoyの仕事

McCoyは、ここまでの話で出てきたうちの、「update.rdfに署名を施す」「その署名を検証するための公開鍵をinstall.rdfに埋め込む」の部分を担当するソフトウェアだ。（なお、秘密鍵と公開鍵のペアは自動的に生成されるので、アドオン作者自身が秘密鍵の存在を意識することはない。）使い方はリンク先の文書か、くでんさんによる解説を読んで欲しい。

McCoyではできないこと

McCoyを使うことで「自動更新をセキュアにする」ことはできる。でも、その前のステップである「そのアドオンを初めてのインストールをセキュアにする」ことはできない。初めてインストールする時の時点で偽物のインストーラを掴まされた場合、この仕組みは破綻してしまう。

初めてのインストールをセキュアにするためには、そのアドオン自体に署名を付けるか、SSLを使って配布するか、ハッシュを比較するしかない。しかし……

• XPIインストーラに署名を付けるには、会社の登記簿謄本が必要で、お金もかかる。実質、企業限定の方法である。
• SSLを使うには、SSLを使えるサーバを調達するコスト、認証局証明書を購入するコストがかかる。
• ハッシュを比較させるには、そもそも、比較用の「正しいハッシュ」を何らかのセキュアな方法で提供しなければいけない。結局の所、SSLを使わずに、アドオン作者がユーザに対してセキュアにハッシュを渡す方法は、実質的には無いと言っていい。

などの問題がある。

SSLが使えるのであれば、McCoyを使ってupdate.rdfに署名を施す必要性は薄い。自前でSSLが使えるサーバを用意できるなら問題ないし、そうでなくても、Mozilla Add-onsでは標準でSSLを使用しているので、ここにアドオンを登録しさえすれば初回インストールも自動更新も全部がセキュアになる。よって、McCoyが本当に必要になる場面は、以下のどちらかの場合ということになる。

• 最初のインストールに関しては、データの手渡しやイントラネットの配布、署名されたメールでの配信など、何らかの方法で確実性を保証することができる。
• Mozilla Add-onsに登録することができないアドオンである（社内用に秘密裏に開発・配布しないといけない、など）。

ちなみに、僕は自動更新はMcCoyを使ってセキュアにしているけれども、初回インストールについては、セキュアでないことを承知の上で普通にhttpで署名無しのXPIインストーラを配布している。この点については責められてもしょうがないので何も言えない。

Mozilla Add-onsの問題

個人のアドオン作者としては、配布場所をMozilla Add-onsに一本化できるならそれが一番セキュアだし簡単便利だし（今はMozilla Add-onsのUIは日本語化されていて、英語ができなくてもアドオンを簡単に登録できる上、ここに登録すればupdate.rdfもMozilla Add-ons側で提供してくれる）で万々歳なんだけれども、唯一のネックがあって、それは、「一般ユーザから見える場所に置かれるには時間がかかる」ということ。

新しく作成したアドオンは「レビューがついて」「作者が公開申請をして」「そのレビューの内容が妥当と認められて」「エディタが公開を認める」まてずっと一般ユーザの目からは隠されたままになる。また、公開されたアドオンの新しいバージョンをアップロードしても、「エディタがそのアップデート版を検証して、問題ないと確認されて」初めて一般ユーザ向けに公開される。このタイムラグが、Mozilla Add-onsを全面的にお勧めしづらい最大の理由だ。先日もXUL/Migemoのアップデート版が公開を承認されるまで1ヶ月以上かかってしまっていたし、現実的に、このレビューの仕組みはすでに破綻していると言っていいと思う。

せめて、「レビューされていようがいまいが、エディタの審査をパスしていようがいまいが、一般ユーザから自由に見ることはできる」「ただし、レビューされていなかったり、エディタの審査をパスしていなかったりする物については、それ相応の警告を出す」という風な運用に変えてもらえれば、それで十分Mozilla Add-onsに一本化できるんだけど……