高木浩光＠自宅の日記

■ オレオレ警告の無視が危険なこれだけの理由

「オレオレ証明書」の問題が広く認知されるようになってきたのはよいが、オレオレ警告が出たとき、「お、オレオレじゃん。どうなってんの？このサイト」と、野次馬的に興味本位で「はい」を押して先を見に行ってしまう人も出てきているのではないかと心配になった。

つまり、人々の行動は、知識の持ち様によって次のように分類できるのではないか。

1. 何も知らないが、出た警告に危険そうなことが書かれているので、常に「いいえ」を押すようにしている人
2. 大学や自治体サイトに「問題ありませんので」と書かれているのを見たことがあるので、「はい」を押して先に進むのが普通と思っている人
3. 「オレオレ証明書」という話を聞いたことがあるので、これが出るサイトは駄目サイトだと思っていて、どうなっているか見に行ってしまう人
4. 「オレオレ証明書」のことは理解しているつもりで、警告を無視したアクセス先で重要な情報（パスワード等）の入力さえしなければ問題ないと思っていて、どうなっているか見に行ってしまう人
5. 正しく理解していて、オレオレ警告が出たときは常に「いいえ」を押すようにしている人
6. 正しく理解していて、オレオレ警告が出たときは基本的に「いいえ」を押すようにしているが、正しい手順を経てその先を見に行くこともある人

「オレオレ警告が出たらそこは駄目サイト」という理解は誤りだ。閲覧している人がそのタイミングで（通信路上で）攻撃を受けているだけで、サイト自体は正常である場合もある。オレオレ証明書が問題なのは、サイト自体が異常な設定をしていると、サイトが異常なのか、閲覧者が攻撃を受けているのか、区別つかないという点にある。上記のうち正しい行動は、1.と 5.と 6.だけである。

これまで、オレオレ警告時は「いいえ」を押してアクセスしないのが当然であるとし、もし「はい」を押して先に進んだ場合にどんな危険があるのかについては、あまり具体的に整理してこなかった。上記4.のパターンの「重要な情報（パスワード等）の入力さえしなければ問題ないと思っていて、どうなっているか見に行ってしまう」という行動が、どのように危険なのかを以下に整理してみる。

ログイン中のセッションをハイジャックされる

たとえば、銀行やネットショップでログイン中のとき（パスワードを送信するときは警告は出なかったとして）、あるタイミングでオレオレ警告が出たとしよう。「あ、オレオレ証明書じゃん。どうなってんの？このサイト」と、とりあえず警告を無視して先に進んだとしよう。その瞬間何が起きるだろうか。

つまり、図1の画面で「はい」ボタンを押した瞬間、また、図2の画面で「推奨されません」のリンクをクリックした瞬間、図3の画面で「OK」ボタンを押した瞬間、図4の画面で「承認する」ボタンを押した瞬間、図5の画面で「Continue」を押した瞬間、図6の画面で「続ける」を押した瞬間、図7の画面で「はい」を押した瞬間、何が起きるだろうか。

図1: Internet Explorer 6 のオレオレ警告

図2: Internet Explorer 7 のオレオレ警告

図3: Firefox 2 のオレオレ警告

図4: Opera 9 のオレオレ警告

図5: Safari 3 のオレオレ警告

図6: iPod touch のオレオレ警告

図7: PSP のオレオレ警告*1

警告を無視して先に進むと、その瞬間、HTTPのリクエストが cookie付きで送信される。

もし通信路上に盗聴者がいた場合*2、そのcookieは盗聴される。セッションIDが格納されているcookieが盗聴されれば、攻撃者によってそのセッションがハイジャックされてしまう。

「重要な情報さえ入れなければいいのだから」という認識で、オレオレ警告を無視して先を見に行ってしまうと、ログイン中のセッションをハイジャックされることになる。

今見ているのとは別のサイトへアクセスしようとしているのかもしれない

さすがに、銀行を利用している最中でオレオレ警告が出たときに、興味本位で先に進む人はいないかもしれないが、銀行を利用した後、ログアウトしないで、別のサイトへ行ってしまった場合はどうだろうか。通常、銀行は数十分程度で強制ログアウトさせる作りになっているはずだが、その数十分の間に、通信路上の盗聴者により、銀行サイトへリダイレクトさせられた場合どうだろうか。

閲覧者としては、ニュースなどを読んでいる最中に突然オレオレ警告が出るという体験をする。ここで、ニュースサイトが出している警告だと思い込んで、そのまま「はい」で先に進むと、さっきまで利用していた銀行にアクセスしてしまい、送信するcookieを盗聴されてしまう。

このことは、17日の日記「こんな銀行は嫌だ」の件に関係する。電話で問題点を指摘した際、こんなやりとりがあった。

私: この文書はいつ削除するんですか？ 間違ったことが書いてあるんですが。

銀: ……。それも含めて検討……

私: どういう責任を感じてるんですかね。これ間違ったことを、嘘を教えているわけでしょ？ おたくのユーザに、赤くなってても使って大丈夫だと教えてるわけでしょ？ 推奨されませんとまで書いてあるのに、それを押せと、言ってる。「セキュリティ上の問題はございません」て書いてあるでしょ？ そういうものだって理解しますよね？ これ読んだ人は。赤くなっていても問題ないのだと、教えられるわけですよね？ そういう誤った知識を植えつけてしまったことに対する責任をどう考えてるんですか？ おたくは。

銀: ……。ううん……。……。それも含めて検討させてもらればと思いますが。

私: どういうふうに検討されるんですか？ 間違ったことを書いてましたと、赤くなってるときは使ってはいけないのに、

銀: 赤くなってるときは使ってはならないと、

私: 推奨されませんと書いてあるじゃないですか。

銀: そうですね。はい。……。推奨されませんとなった理由は上の方に記載の通りなんですけども、

私: ええ。けれども？ なんですか？

銀: あのー……。そうか……。……。これは、すべての場合のInternet Explorerをご利用の場合にというアナウンスではないんですけどもね。

私: 何がですか？

銀: Internet Explorer 7で推奨されませんと出たときの、すべての場合でそのまま押してくださいと申してるものではないんですども。

（以下略）

つまり、銀行側の言い分として、この警告を無視してよいと言っているのは「ビジネス情報サイト」についてだけであって、他のサイトについては言っていないというわけだ。しかし、次の被害シナリオが考えられる。

この銀行のインターネットバンキングを利用した人が、インターネットバンキングをログアウトしないで、「ビジネス情報サイト」を閲覧しに行ったとする。このとき、通信路上の盗聴者が、閲覧者のブラウザをインターネットバンキングのサイトへとリダイレクトさせ、通信路上でサーバ証明書を攻撃者所有の証明書に置き換えたとする。そうすると閲覧者のブラウザにはオレオレ警告が出るわけだが、閲覧者は、いつもの「ビジネス情報サイト」にアクセスしようとしていると思っているので、そのオレオレ警告を無視して「はい」を押してしまう。この瞬間、インターネットバンキングサイトに（盗聴されながら）アクセスすることとなり、cookieを盗聴され、セッションハイジャックされてしまう。

もっと酷いことに、これはその銀行だけで被害が済む話ではない。閲覧者が、他の銀行であるメガバンク等にも口座を持っていて、メガバンクのインターネットバンキングにログインしている最中に、この地銀の「ビジネス情報サイト」を閲覧しに行ったら、真面目にサイトを作っているメガバンクの方で被害が出てしまう。

このように、たかが「ビジネス情報サイト」だからどうでもいいという話ではない。

脅威はcookie漏洩だけではない

cookie窃用によるセッションハイジャックだけならば、たいして重大でない場合もある。セキュリティを重視したサイトでは、たとえセッションハイジャックされても重大な被害が出ない構成にしていることがある。たとえば、個人情報を閲覧する画面に入る際には再びパスワードの入力を必要とするとか、振込み操作を実行するにはワンタイムパスワードの入力を必要とするといった構成だ。*3

しかし、cookie窃用によるセッションハイジャックとは異なり、今想定しているケースでは、通信路上に盗聴者が入っている（SSLを使っているのにオレオレ警告を無視した）のであるから、常時、通信内容を盗聴されたり改竄されている可能性がある。

したがって、本人が、個人情報閲覧画面に入ろうとしてパスワードを送信したとき（そのパスワードも盗まれるが）閲覧する個人情報は盗聴されるし、また、たとえワンタイムパスワードを使っていても、9月23日の日記で書いたman-in-the-middle攻撃の場合と同じ危険がある。（IE 7 ではアドレスバーが赤くなっているので異常な状況を判別できるが、それ以外のブラウザでは、オレオレ警告を無視した後の状態であることを判別できない。）

銀行では比較的短時間で強制ログアウトさせられるが、長時間ログインしっぱなしで使う、ブログやSNSサイト等では、これが現実となる可能性がより高くなるだろう。

警告は1度しか出ない

また、ログイン中でなければ大丈夫というものでもない。オレオレ警告は1度しか出ない点に注意が必要である。

あるタイミングでオレオレ警告が出たとする――(a)。「ログイン中でないから大丈夫だろう」「何も入力しなければ大丈夫だろう」と興味本位で先に進めてみたとする。そのときは何も起きなかったとする。それから何日かして、そのことをすっかり忘れているときに、インターネットバンキングを利用するとき、実はそれは盗聴されているということが起こり得る。

つまり、(a)のオレオレ警告は通信路上の盗聴者がしかけたオレオレ証明書によるものであり、それを一旦受け入れてしまった閲覧者は、その後、同じ盗聴者がいる通信路上でアクセスすると、警告なしに盗聴されてしまう。ログインしようとパスワードを送信する時点から盗聴される。（IE 7 ではアドレスバーが赤くなっているので異常な状況を判別できるが、それ以外のブラウザでは、オレオレ警告を無視した後の状態であることを判別できない。）

これを回避するには、ブラウザを再起動する必要がある。昨今のWindowsは安定して動くので、何週間にもわたって起動しっぱなしで使うのが普通になっている。iPod touch の場合は Safariを再起動する手段さえ用意されていない（11月23日の日記参照）（12月8日訂正：11月23日の日記の追記参照）。

証明書の内容を確認すれば大丈夫？

オレオレ警告をあえて無視して先を見に行こうとするとき、証明書の内容を確認すれば大丈夫と言えるだろうか？

たしかに、警告の内容と証明書の内容によっては見に行って大丈夫な場合もある。しかし、大丈夫かどうかは、素人には判別が難しい。

たとえば、11月17日の日記の地銀ネットワークサービスのビジネス情報サイトの場合、発行先が「www.cns-jp.com」となっていて、アクセス先のサーバと食い違っているために警告が出ている。したがって、証明書の内容を表示させて確認し、発行先が「www.cns-jp.com」であることを目視確認すれば、見に行っても大丈夫だと言うことも可能だ（ブラウザによっては）。

しかしそのとき、証明書の発行者が正規の認証局であることも同時に確認しなければならない。つまり、Intnernet Explorer ならば、図8の (a) と (b) のどちらなのかを見分けなくてはならない。

(a)

(b)

図8: 2種類のオレオレ警告

証明書の仕組みを理解していない一般の人々に対して、これらを見分けろというのは酷な話だろう。

PSPの場合、図7の1つ目と2つ目の警告を見分ける必要があるが、それらの意味の違いをいったいどれだけの人が理解できるというのだろう？

また、Internet Explorer 7 では、アクセスする前に証明書の内容を確認することができなくなった。図2のように、証明書を確認するためのボタンやリンクは存在しない。確認するには、一旦「このサイトの閲覧を続行する（推奨されません）」をクリックして先へ進み、図9の「証明書のエラー」となっている部分をクリックして初めて証明書の内容を閲覧できる構造になっている。その画面を見た時点で既に盗聴者にcookieが送信されているので、後の祭りだ。

図9: Internet Explorer 7で先に進んだ画面の様子

iPod touchにいたっては、証明書の内容を確認する機能がそもそも存在しない（上記の図6および、10月20日の日記参照）。

Firefox 2 と Safari 2 におけるもう一つの危険

加えて、Firefox 2 と Safari 2 には別の危険性があることが、先週 Bugtraqに投稿された記事で指摘された。

• Phishing for Confirmations - Certificate spoofing with subjectAltName and domain name wildcards, Nils Toedtmann, 2007年11月20日

オレオレ警告を無視してしまうと、その後、同じオレオレ警告は出なくなるわけだが、「同じ」というのはどこで判別されるのか。

Firefox 2 では、証明書単位で覚えておく実装になっているようだ。そのため、次の挙動が起こり得る。

• サイト A へ接続する際に、不明な認証局から発行されたオレオレ証明書（ホスト名は A として発行されている）が提示された場合、
• ブラウザは図3のように「未知の認証局により認証されています」という警告を出すが、
• ここで閲覧者が（警告を無視して）この証明書を受け入れた場合、
• その後、サイト B に接続する際に、攻撃者によりその証明書が提示された場合、
• ブラウザは、「未知の認証局により認証されています」の警告は省略するけれども、ホスト名が B であるはずのところ A になっているという警告（図10）を出す。

図10: Firefox 2 におけるホスト名が異なることを示す警告

これだけならば問題はないと言うこともできる。

つまり、サイト A でオレオレ証明書を受け入れた閲覧者は、証明書の内容を目視確認して、サイト A 用の証明書だと承知の上で受け入れたのであろうから、サイト A で盗聴の危険に晒されるのは閲覧者の自己責任である ―― という立場をとることが可能だ。

もし、サイト A への接続時に、図3の警告だけでなく図10の警告も現れて、そのオレオレ証明書がサイト B 用のものであると示されていた場合は、閲覧者は、B が重要なサイトでないかを確認しなければならない。もし、B が重要なサイトなのにそのオレオレ証明書を受け入れてしまうと、後に B のサイトへ行った際に、警告は出ず、盗聴されてしまうことになる。

したがって、Firefox 2 では、オレオレ警告時に見るべきは証明書の発行先のホスト名であると言える。

具体的に言うと、たとえば「ビジネス情報サイト」を訪れたときに、通信路上の盗聴者により、攻撃者自作のオレオレ証明書が提示されたとする。まず図3の警告が出るが、「『ビジネス情報サイト』だからどうでもよい」という判断でこれを受け入れたとする。さらに図10の警告も出たときに、内容をよく見ないで受け入れたとする。そのとき、実は図10の警告に、

"www.○○bank.cns-jp.com" との接続を確立しようとしていますが、このサーバが使用している証明書は、"ib.○○bank.co.jp" のものです。

と書かれていたとすると、それは危険な状態となる。インターネットバンキングの本物サイトである、「https://ib.○○bank.co.jp/」にアクセスしたときに、通信路上で盗聴者がその偽サーバ証明書を使っていても警告が出ない事態となる。

閲覧者は、オレオレ警告を無視するときは、「"○○" のものです」の部分を目視して、どうでもよいサイトであることを確認しなければならない。これを怠るのは閲覧者の自己責任である ―― というわけだ。Firefox 2 はそのような方針で作られていると言える。

ところが、先週Bugtraqに投稿された指摘によると、証明書の「subjectAltName」欄まで見なければ、確認したことにならないという。

図10で「"○○" のものです」と表示されているのは、証明書の「Subject」欄の「CN」欄の文字列になっている。ところが、証明書の標準規格である「X.509」（RFC 3280参照）は「subjectAltName」という欄を定義しており、ここにも証明書の有効なホスト名を記載できるようになっている。そして、最近のWebブラウザはこの「subjectAltName」をサポートしており、この欄も見ている。

Firefox 2 は、図10の警告で「"A" のものです」と表示していても、それは「Subject」欄の「CN」欄の値であって、それとは別に「subjectAltName」欄に「B」と書かれていたなら、その証明書を受け入れてしまうと、B のサイトに行ったときに盗聴されていても警告が出ないという事態になってしまう。

そのため、指摘者は、図10の警告で「subjectAltName」欄の内容も表示するべきだという提案をしている。

これに対し、Mozillaプロジェクトは、Firefox 2 では直さないとしているそうだ。（先ごろベータテストが開始されたばかりの）Firefox 3 では、オレオレ警告の出し方を変更しているためこの問題はないようだ。

セキュリティにかかわる件であるのに直さないというのは、このケースでは理解できる。なぜなら、そもそも、オレオレ警告を無視しながら安全に使おうとすること自体に無理があると思うからだ。

ちなみに、Intrenet Explorer と Opera にはこの問題がないとのこと。Internet Explorerでは、オレオレ警告を無視した後の「同じオレオレ警告の省略」は、アクセスしたサイトのホスト名ごとに管理しているらしい。つまり、サイト B 用に発行されたオレオレ証明書をサイト A への接続時に無視しても、サイト B に接続するときには、同じオレオレ証明書が提示されても再び警告を出すようになっているようだ。

Firefox 3 ではどうなるのか

Firefox と Internet Explorer を比較すると、オレオレ警告に対してユーザがどう対処するべきかの考え方に違いがあるように思える。

Firefox は、ユーザの自己責任の下、証明書の内容を確認して受け入れる仕組みを用意する方向性で設計されている。対して、Internet Explorerは、IE 7 での改良で、警告時に証明書の内容を表示する機能を省いてしまい、そもそも確認できないように設計変更された。これは、「ユーザに確認することは無理だから、警告発生時にはアクセスを継続するな」（「推奨されません」）という方針で設計されていると言えるだろう。

Firefox はプロ向け、マニア向けと言えるかもしれないが、受け入れても大丈夫な証明書であることをきちんと確認できるだろうか。

先週ベータテスト配布が始まった Firefox 3 では、オレオレ警告は図11のようになる。

図11: Firefox 3 におけるオレオレ警告

IE 7 と同様に、ダイアログウィンドウでの警告はやめて、画面全体でエラーが表示されるように改善された。（どのサイトにアクセスしようとして出たエラーなのか、アドレスバーで確認できるようになっている。）

それでもアクセスを継続する手段は残されているのだが、IE 7 と異なるのは、IE 7 では「証明書のエラー」のまま、アドレスバーの赤い表示でアクセスを継続させるのに対して、Firefox 3 では、証明書の内容を確認して、証明書を登録してからアクセスするようになっている。図11の「例外として扱うこともできます」の部分をクリックすると、図12のようになる。

図12: Firefox 3 におけるオレオレ警告（続き）

「例外を追加」ボタンを押すと図13のウィンドウが現れる。ここで何を確認すれば安全と言えるのか、一般の人たちにそれが理解可能だろうか？*4

たとえ、それぞれのブラウザで安全にオレオレ警告を扱う方法が用意されているとしても、それは、たまたまそのブラウザがそのような実装になっているというだけで、SSLの仕様に基づいた挙動ではないという点に注意したい。サーバ証明書の正当性検証ができない状況は、致命的エラーなのであって、そのときに例外的に扱う方法は定義されていない。

図13: Firefox 3 曰く「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません」

「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません」とあるように、本物の銀行や公共サイトがこのような操作を強いることがあってはならない。

また、Firefox 3 の「セキュリティ例外を承認」の機能は、興味本位で見に行くためのものではない。Firefox 2 までの「このセッションの間だけ一時的に証明書を受け入れる」（図3）の機能は廃止された。「セキュリティ例外の承認」は、「今後この証明書を受け入れる」を選択した場合に相当する。「証明書マネージャ」（図14）で受け入れ済み「サーバ証明書」のリストから削除するまで、この状態は続いてしまうので注意が必要だ。

図14: Firefox 3 の「証明書マネージャ」

結論

話が長くなったが結論は単純で、「オレオレ警告が出たらいかなる場合もアクセスを中止すること」と心得ておけばよい。

興味本位でオレオレ警告の出るサイトを見に行く場合には、十分な知識を持って適切な手順でブラウザを使用しないと、被害に遭う危険性がある。