高木浩光＠自宅の日記

■ 無線LANのMACアドレス制限の無意味さがあまり理解されていない

職業マスメディアに代わって、ブログスタイルのニュースサイトが人気を博す時代になってきた。海外の話題を写真の転載で紹介する安直なニュースも人気だ。

このことろなぜか、無線LANのセキュリティ設定について書かれた記事を何度か見た。おそらく、ニンテンドーDSがWEPしかサポートしていないことが不安をもたらしている（そして実際に危険をもたらしている）ためだろうと思われる。

セキュリティの解説が増えてきたのはよいことなのだが、内容に誤りのあるものが少なくない。

• 実は危険な無線LAN, らばQ, 2007年10月21日

この記事には次の記述があるが、「接続されなければMACアドレスは盗まれない」という誤解があるようだ。

MACアドレスというのは、機器固有のIDのようなものです。たいていの無線LANアクセスポイントにはMACアドレスフィルタリングの機能がついており、接続する機械の MACアドレスをあらかじめ登録しておくことで、未登録のMACアドレスを持った機器が繋がらないように設定できます。

ただし、MACアドレスはものによっては書き換える事が可能で、登録してあるMACアドレスのリストなどが盗まれた場合などは簡単に侵入されてしまいます。

しかし、そもそもLANに接続できなければそう簡単には盗まれないですし、総当たりするのも簡単ではないですから、多少はセキュリティ向上が期待できます。

実は危険な無線LAN, らばQ

これについて次のように追記で訂正されたが、その訂正内容も間違っている。

無線LANの通信を傍受し、暗号を解読してしまえばMACアドレスは漏洩するとのことです。確かに考えてみればあたりまえですね。すっかりボケてました。すみません。

実は危険な無線LAN, らばQ

MACアドレスは暗号化されない。

どうも、MACアドレスがどういうものかイメージがわかないまま、「MACアドレスによる接続制限」のことが語られているようだ。ここはもうズバリどういうことなのかを示して、誰でもイメージをつかめるようにしておくべきだと思うので、次の図をここに示しておく。

図1は、無線LANの管理用ソフトウェアを用いて、傍受したWi-Fi信号を表示させた様子だ。（自分の無線LAN機器間の通信を自分で傍受したもの。）

図1: 傍受したWi-Fi信号をそのまま表示した様子

このように、Wi-Fiの電波信号は、データ（ピンク色の部分）に対してヘッダとして「送信元MAC」アドレスと「送信先MAC」アドレスを付加して（図中の矢印の部分）飛ばされている。暗号化されている部分はピンク色の部分にあり、ヘッダ部分は暗号化されていない。

したがって、攻撃者は、侵入しようとする無線LANの近くで正規接続者の通信信号を傍受することにより、正規接続者のMACアドレスを知得し、同じMACアドレスを設定した無線LANクライアントで接続してしまう。

これは、有線LANにおけるMACアドレス接続制限と違って、不正接続の防止効果が格段に小さい。有線LANでは接続するとMACアドレスが見えるのに対し、無線LANでは接続しなくても見える。

このことが意外に理解されていないようで、たとえば以下のブログでも、「接続すれば見える」かのようなことが書かれていた。

• セキュリティのセの字も考えてないライブドアの公衆無線LANサービス, Web屋のネタ帳, 2006年12月25日

  MACアドレスのよくある誤解その２： 「MACアドレスはその機器（PC等）の持ち主しか知りえない」

  そんなわけない。Windowsのコマンドプロンプトを開いて「arp -a」とたたいてみよう。

  このように、同じLANにいる隣近所のマシンのMACアドレスを見ることができる。（略）

  別にこんな技術的なテクニックを使わずとも、NICカード（orそれを搭載した機器）そのものにMACアドレスが書いてあったりすることもある。

こういう中途半端な理由を挙げていると、むしろ半可通のセキュリティ屋に「やれることはやっておくのがセキュリティの常識なんですよ」などとナンセンスなことを言わせる隙を与えるだけだろう。「接続しなければ見えないのだから」とか、「部屋に侵入されなければNICカードに書かれたMACアドレスを見られることはないのだから」とか、むしろ誤解を誘発してしまう。

WPAによる暗号化が有効に働いていれば、鍵を知る者以外には接続できないのだから、MACアドレス接続制限をする必要性は全くない。

それなのに、なぜか、「暗号化で秘匿」「MACアドレスで接続制限」の両方が必要だと勘違いした解説がたくさん出回っている。

• 安全な無線LANの利用, 国民のための情報セキュリティサイト, 総務省, 更新日不明

  無線LANを安全に利用するためには、少なくとも以下の3つの設定をすべて行ってください。（略）

  1. WPA-PSK方式等による暗号化を行う。
  2. MACアドレスによるフィルタリングを設定する。
  3. 外部の人にSSIDを簡単に分からないように設定する（推測しにくいIDにする、SSIDを見えなくするためのステルス機能を利用する）。

• 安全な無線LANの利用 アニメーションで説明を見る, 国民のための情報セキュリティサイト, 総務省, 更新日不明

  下の図のように、出鱈目な解説がされている。

  

• 「ウォーサイクリング」体験談つき　無線LANのセキュリティ対策1, All About, 2004年6月9日

  SSIDがわかってしまえば、後述する「MACアドレスフィルタリング」などのフィルタリング方法を併用しない限り、暗号化されていようがいまいがアクセスポイントに接続できてしまいます。

  （略）

  3つの対策がすべて必要である理由が、おわかりいただけたでしょうか？

• 無線ＬＡＮのセキュリティは、こうやって設定をしよう, 三田 典玄, オーマイニュース, 2007年6月6日

  ということで、無線ＬＡＮのセキュリティー対策は、通常、上記の「１−２」、「１−３」、「１−４」という組み合わせで行われる。つまり、通常はＭＡＣアドレス制限で接続できるパソコンを制限したうえ、無線でやりとりされるデータを暗号化するという方式をとるわけだ。

• 見えないからこそ注意を払うべき 「無線LAN」のセキュリティ, SAFETY JAPAN 特集, 日経BP, 2007年9月12日

  （略）前項で述べたAES機能を設定すればいいだろう。

  このとき、無線LANクライアントで一度接続を行った後は、各LAN機器が持つ固有の「MACアドレス」を無線LANルーターに登録し、それ以外の MACアドレスからの接続は受け付けないように設定しておく。こうすることで、登録していない無線LAN機器からの接続は事実上できなくなる。

どうしてこんなことになってしまっているのか。「国民のための情報セキュリティサイト」が読まれて誤解が広まっているのかもしれないが、archive.orgの記録によると、そのページは以前は（たとえば2007年5月5日の時点で）次のように書かれていたようだ。

無線LANを安全に利用するためには、少なくとも以下の3つの設定をすべて行ってください。（略）

1. WEPによる暗号化を設定し、暗号化鍵を定期的に変更する。
2. MACアドレスによるフィルタリングを設定する。
3. 外部の人にSSIDを簡単に分からないように設定する（推測しにくいIDにする、SSIDを見えなくするためのステルス機能を利用する）。

いまどきWEPはないだろうということで、誰かが指摘したのか、現在は「WPA-PSK方式等」に修正されている。

たしかに、この解説が最初に書かれたころの昔は、WEPしか使えない現実があった。そして、WEPの脆弱性が指摘されて、WEPでは危ないということが知られていた。そうすると、「どう設定すればよいか」の解説を書かされる人は困ってしまう。解決策がないからだ。しかたなく、苦肉の策として「とりあえず3つやっておけ」と書いてお茶を濁さざるを得なかったのかもしれない。

そうすると、その種の解説を読んだ半可通が、「キリッ」とした顔で、

鍵破り対策は「破られないこと」より「破る手間を増やすこと」が重要です。「破れない鍵」が存在しない以上、手間を増やして時間をかけさせ、その間に諦めさせたり、鍵破りを検知したりして対応するわけです。

実は危険な無線LAN, らばQ

てなことを言い出してしまう。

WEPを使用せざるを得ないときに、MACアドレス接続制限を加えることに意味があるかというと、全く意味がない。なぜなら、WEPの暗号をクラックする際には、同時にMACアドレスも見えているからだ。

一般向けの対策はシンプルでなければ普及しない。WPA、WPA2を使用し、適切な鍵設定をすることだけを奨めればよいだろう。SSIDはどうでもいい。

参考にするのに相応しいのは次の資料だと思う。

• 安心して無線LANを利用するために, 無線LANセキュリティ調査研究会編, 総務省

この資料では、p.16とp.17で、「家庭 レベル2」「オフィス レベル2」の対策として、WPA-PSKを挙げており、そこには「MACアドレスフィルタリング」「SSID」の記述はない。

なお、鍵はには「13文字以上の文字列を設定することが望まれます」とある。昨今の無線LAN機器では、pre-shared key のことを「パスワード」と表現するものがある（iPod touch など）ため、誤解を招いて、8文字程度のものを付けてしまうことがありそうだが、注意したい。

ところで、元の話題に戻って、ニンテンドーDSがWEPしかサポートしていないことにどう対処するかだが、最近は、家庭向けの無線LANルータでも、「マルチSSID」「マルチAP」あるいは「マルチセキュリティ」などと呼ばれる、複数の無線ネットワークを提供して別々の暗号化設定を選べる機種が売られている。

• マルチSSID, NEC
• マルチAP機能, コレガ
• 無線LAN暗号化レベル“AES”“TKIP”“WEP”を混在利用できる「マルチセキュリティ」機能搭載, バッファロー

これらを買えば、家庭内LAN用にWPA設定したネットワークを使い、それとは別に、家庭内LANから分離されたWEP設定のネットワーク用意してニンテンドーDS用に使うというわけだ。

それによって何が解決するかというと、まずその前に、WEPの暗号が破られることによる脅威には何があるかを確認しておくと、

1. 通信内容を盗聴されたり改竄されたり、あるいは、偽のアクセスポイントに誘い込まれて、その結果として、秘密を知られたり、パスワードやクレジットカード番号を盗まれたり、ログイン状態を乗っ取られてお金を盗まれたりする。
2. LANに侵入されて、LANに接続されたコンピュータに認証のかかっていないものがあれば、そこからファイルを盗まれたりする。
3. インターネット接続回線を勝手に使用され、悪いことに使われた場合に、犯人の嫌疑をかけられる。

の3つに分けられるわけだが、このうち、1. と 2. は解決する*1。（ただし、ニンテンドーDSからはLANのサーバに接続するのを諦め、ニンテンドーDSからのアクセスは盗聴されてもかまわない利用しかしない*2と諦める。）

しかし、3. は解決しない。この問題をどう考えるか。

いっそのこと、Fonを設置して、公開用ネットワーク（FON_AP）の方を使ってはどうかと考えた（その場合、攻撃者はFONにログインする必要が生じて足がつく？*3ので、責任をFon運営者に転嫁することができるかも？）が、ニンテンドーDSにはブラウザがない（別売り）ためログインできないのだとか。*4

じゃあ、近くの電柱にlivedoor Wirelessのアクセスポイントがあるなら、ニンテンドーDSのMACアドレスを登録してlivedoor Wirelessにつなぐとか。しかし、この場合も、MACアドレス盗聴により、成りすまして使われる可能性があるという意味では、3.と同様の脅威は生ずる*5。

どうしようもないので、3. の問題は当面諦めるしかないのでは。2つの無線ネットワークを使用し、WEPに設定した方のネットワークは電波を弱くして、アクセスポイントの近くで遊ぶようにするくらいしかない。その意味で、USB型のアクセスポイント（「ゲーム機専用」などと謳われている）を用いると、（アルミホイルなどで）電波を弱めやすく、都合が良いのかもしれない。

なお、WEPをクラックして他人の無線LANを勝手に使う行為は、電波法第109条の2により、罰則付きで違法行為とされている。

電波法 第109条の2

暗号通信を傍受した者又は暗号通信を媒介する者であつて当該暗号通信を受信したものが、当該暗号通信の秘密を漏らし、又は窃用する目的で、その内容を復元したときは、1年以下の懲役又は50万円以下の罰金に処する。

2 無線通信の業務に従事する者が、前項の罪を犯したとき（その業務に関し暗号通信を傍受し、又は受信した場合に限る。）は、2年以下の懲役又は100万円以下の罰金に処する。

3 前2項において「暗号通信」とは、通信の当事者（当該通信を媒介する者であつて、その内容を復元する権限を有するものを含む。）以外の者がその内容を復元できないようにするための措置が行われた無線通信をいう。

4 第1項及び第2項の未遂罪は、罰する。

5 第1項、第2項及び前項の罪は、刑法第4条の2の例に従う。

また、他人の無線LAN機器のMACアドレスを詐称して、制限されたネットワークに接続する行為は、不正アクセス禁止法第3条2項2号または3号の不正アクセス行為に該当する可能性があるかもしれない*6。

もっとも、詐欺などのより悪質な罪を犯そうとする者に対してこれらの法律が抑止力になるのかどうか……。ただ、民事上の名誉毀損に問われ得る掲示板書き込み等に対しては、これらが抑止力になりそうではある。

といったところか。

■ 最終回： PlaceEngineの次に来るもの そしてRFIDタグの普及する未来

この日記を書き始めたいきさつは、2003年の春、RFIDタグのプライバシー問題について、何が問題なのかあまりに理解されないことに危機感を覚え、ひとつひとつ書いていこうと決意したことからだった。

当時いろいろな方とお話しした中で最も印象に残っているのは、日経デジタルコアのイベントの宴席の2次会で同じテーブルについてお話しする機会のあった泉田氏との議論だった。そのときのことは2003年7月4日の日記に記録がある。その泉田氏は現在の新潟県知事である。

泉田氏はこうおっしゃった。「プライバシーが問題になるとしたら、政府がRFID読み取り網を整備するようなことになったとき。そうでなければ無理。」

つまり、街中にRFID読み取り機が設置され、そしてそれがネットワークに接続されるような状況は、国などが敷設しない限りありえない話だということだった。たとえば、警察が Nシステムと同様の目的で RFID監視網を設置するような状況などが考えられ、他にそういう需要がないという話になった。

それに対し私は、民間が、たとえばコンビニ店とかが、それぞれの必要性で設置したRFID読み取り機が、全体として繋ぎ合わされることによる脅威があるので……とか、街中にと言っても、300メートルおきである必要はなく、数キロ間隔であってもプライバシーの問題にはなるので……ということを言った記憶がある。

あれから4年。PlaceEngineが実用化され、付加サービスも開始され、着々と既成事実化されようとしている。

• 無線LANの電波で半径3kmのラーメン店を検索できる「x-らーめんRadar」, INTERNET Watch, 2007年11月1日

  なお、x-らーめんRadarを起動させてタスクトレイに常駐させている場合、同時に起動する「PlaceEngine」が5分起きに位置情報を再取得するため、目的地と自分の位置関係も確認できる。

現在のPlaceEngineは、観測される無線LAN信号のうち、アクセスポイントが発するビーコン信号だけを選別して用いている。これは、PlaceEngineの目的が位置を測定することにあるため、移動することの少ないアクセスポイントの電波を頼りにしているからである。無線LANのクライアント側デバイスは通常、移動することが多いと考えられる（ノートPCや、携帯ゲーム機、iPod等）ため、それらが発する信号はPlaceEngineにとっては無用なものとなっている。

しかし、技術上、ビーコン信号以外の無線LANパケットを活用することも可能だ。つまり、無線LANクライアント側のMACアドレスを活用した、何らかの新たな「ユビキタス」システム/サービスが登場することが考えられる。

昨日の日記の図1でも示したように、無線LANデバイスは、常時、周囲で通信中の無線LAN機器のMACアドレスを受信している。PlaceEngineがそうしているように（図1）専用のネットワークドライバをインストールすれば、こうしたクライアント側デバイスのMACアドレスを取得して活用するソフトウェアを作ることができるだろう。

図1: PlaceEngineがインストールするネットワークドライバ

ただし、さすがに、他人の通信に係るデータパケットを傍受してそのMACアドレスを勝手に使えば、電波法59条に違反すると思われる。PlaceEngineが合法かもしれないのは、送信先MACアドレスが「FF:FF:FF:FF:FF:FF」のブロードキャスト信号であるビーコン（図2）だけを使っているからだろう。

図2: ビーコン信号の例

しかし、実は、無線LANクライアントもブロードキャスト信号を発信している。図3のように、Windows XP の無線LANクライアントは、数十秒間隔で「probe request」と呼ばれる信号をブロードキャスト送信している。

図3: probe request信号の例

図3の送信元「00:16:6F:3X:XX:XX」（「00:16:6F」はベンダIDであるため上部では「Intel」と表示されている）は、私のノートPCの無線LANデバイスのMACアドレスである。このヘッダと共に「SSID: GoogleWiFi」という情報を掲載したprobe request信号がブロードキャストされている。

これは何のために発信されているのかというと、SSIDが「GoogleWiFi」であるアクセスポイントがないか周囲に問い合わせているものだ。もし周囲に、SSIDが「GoogleWiFi」と設定されたアクセスポイントがあれば、そのアクセスポイントがprobe response信号をそのMACアドレスに向けて返すようになっている。*1

この信号を傍受して活用すれば、巷に出回っている各種の無線LANクライアントが、どのように街を移動しているかの情報を蓄積するデータベースを構築することができるだろう。

そうなると、個人の移動履歴を勝手に構築されることにもなり得る。

このことは、RFIDタグのプライバシー問題を懸念していたのと同じことであるわけだが、4年前の私も、これほどまでに簡単にそれが実現し得るとは予想できなかった。というのは、当時の発想では、RFIDタグの読み取り機は固定的に街に設置する必要があると思い込んでいたからだ。その場合、各読み取り機をインターネットに接続してとなると大掛かりであり、誰がそこまでするのかという疑問（泉田氏が言っていたように）があった。携帯電話にRFIDリーダが搭載された場合では、携帯電話は移動しているので、それと同時にGPSで位置も測定しないと、そのRFIDタグがどこに存在したかの記録にならない。そういうことはあまり現実的でないと思っていた。

だが、どうだろう。PlaceEngineが普及しつつある現在、無線LAN搭載機器は、周囲の他の無線LAN搭載機器のprobe request信号の傍受によりそれらの存在を知得するのと同時に、周囲のアクセスポイントからの電波を元にしたPlaceEngineによる位置検索で、現在地を知得できてしまう。

このままラーメンレーダーのようなサービスが普及して、たくさんの人が街で常時、位置情報をと周辺の無線LAN機器の存在を記録（ないしサーバ送信）するようになってくると、他の無線LAN機器を持ち歩いている人々の移動履歴も蓄積されるようになる。

ここで注意したいのは、PlaceEngineの利用者（利用規約に同意している）以外の人たちも、その移動履歴が記録されてしまう点である。また、その移動履歴の記録は、PlaceEngine以外のサービスによって行われる可能性がある。（PlaceEngineと別のシステムが同時にインストールされた無線LAN機器が普及した場合。）

はたして、私達の社会は、そういう未来を受け入れるのだろうか。

勝手に他人の電波を傍受して利用するのは、電波法59条の趣旨にに照らしてどうか。PlaceEngineが合法であるとすれば、無線LANのビーコン信号はそれがブロードキャスト信号である（皆に向けて送信される「放送」である）という理由で、電波法59条の「特定の相手方に対して行われる無線通信」に当たらないと解釈できた場合であろう。その理屈が通るなら、無線LANクライアントのprobe request信号も、ブロードキャストであるから、それを傍受して勝手に利用するのは合法ということになってしまう。本当にそれでよいのだろうか？

ネットワークの低レイヤーにおいて技術上はブロードキャストになっていても、それによって実現する高レイヤーのネットワークは特定の相手との通信であるし、またそれを使用するユーザの意図としても、特定の相手と通信するためのものであることから、ビーコンやprobe request信号は「特定の相手方に対して行われる無線通信」の一部であるとする解釈もあり得よう。

さらに、数年〜10年後、RFIDタグが人々の持ち物に内蔵されるようになり、RFIDリーダ搭載の無線LAN機器が普及した暁にはどうなるか。周囲のRFIDタグのIDを読み取りながら、PlaceEngineで位置を測定して、それらを蓄積するというソフトウェアが普及してしまうかもしれない。2004年10月10日の日記にも書いていたが、他人のRFIDタグのIDを勝手に読み取る行為の電波法59条での扱いもどうなのか。

そろそろこのことについてはっきりさせておかないと、後戻りできなくなってしまうのではないだろうか。

■ ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する

昨日の日記を書いて重大なことに気づいたので、今日は仕事を休んでこれを書いている。昨日「最終回」としたのはキャンセルだ。まだまだ続く。

目次

• Windowsの無線LANはプローブ要求信号として自動接続設定のSSIDを常時放送している
• Windowsの新たな設定項目「このネットワークがブロードキャストしていない場合でも接続する」をオフに
• Windowsの無線LANが放送するSSIDからPlaceEngineで自宅の場所を特定される恐れ
• 電波法59条について再び

Windowsの無線LANはプローブ要求信号として自動接続設定のSSIDを常時放送している

昨日の日記の図3で、probe request信号の例としてSSIDが「GoogleWiFi」になっているものを使った。これは昨日キャプチャしたものだが、周囲に「GoogleWiFi」なるアクセスポイントはないのに、これはどうしたことか。

「GoogleWiFi」で思い出すのは、米国カリフォルニア州のMountain View市でサービスされている、Googleの無料の公衆無線LANサービスである。

• 米Google、地元マウンテンビューで無料の無線ネット接続サービス, マイコミジャーナル, 2006年8月17日

先月、米国出張した際に、Mountain View駅の前のカフェで、このサービスを利用していた（図1）。

図1: Mountain Viewの駅前カフェで無線LANを利用した際の様子

このときの「自動接続」の設定が、私のWindows XPのノートPCに残ったままだったようだ。図2のように、出かけた際にあちこちで利用した公衆無線LANのSSIDを「自動接続」の設定にしたままだった。

図2: Windows XPの「ワイヤレスネットワーク」自動接続設定の様子

Windows XPは、これらのSSIDを全部それぞれ常時、probe requestとして周囲に放送しているようだ。

無線LAN管理用のソフトウェアで、自分のノートPCが発するWi-Fi信号を傍受して観察してみると、各チャンネルに対して、自動接続設定の各SSIDを繰り返し probe requestとして放送しているのを確認できた（昨日の日記の図3）。

普段使わない自動接続の設定は、削除しておいた方がいい。職場や集会や家庭でWi-Fi信号を傍受されると、自分が最近どこへ行ったかがバレてしまうというプライバシー問題があると言える。

そういえばそんな話をどこかで見たような記憶が……と探してみたところ、SANS Instituteがそういう警告を出していた。日本語版のニュースレターも見つかった。

• SANS DVISOR Vol.1, No.3, SANSニュースレター, 2005年9月

  Windows XPでは、802.11ワイヤレスLAN (WiFi)をアクティベートするたびに、優先ネットワークの全てについて接続可能かどうか試される。この「呼びかけ」によりあなたのワイヤレス接続履歴などのワイヤレスクライアントの情報が漏洩してしまう。（詳細はPAGE 3）

SANSは、プライバシー問題だけでなく、セキュリティ上の危険についても指摘していた。つまり、Windows XPマシンを無線LANを有効にして持ち歩いていると、自動接続設定にしているSSIDを常時周囲に知らせてしまうので、攻撃者は、同じSSIDの偽のアクセスポイントを作って誘い込むことがやりやすくなるという話だ。

記憶にあったのはそちらの方の話で、しかしどのみち偽アクセスポイントは避けられないしなあと思っていたのだが、こうして自分で実験してみると、プライバシー問題の方がリアルな問題として気づかされた。

Windowsの新たな設定項目「このネットワークがブロードキャストしていない場合でも接続する」をオフに

さらに調べてみたところ、その後この問題に対処する更新プログラムがMicrosoftからリリースされていたのを知った。

• Windows XP Service Pack 2 用のワイヤレス クライアント更新プログラムについて, 2006年12月（？）

  ブロードキャスト非対応のネットワークに関する変更

  （略）優先するワイヤレスネットワークに一致するネットワークがない場合、ワイヤレスの自動構成機能では、プローブ要求を送信して、優先するネットワークがブロードキャスト非対応のネットワークであるかどうかを確認します。このようにして、Windows XP ワイヤレス クライアントでは優先するワイヤレスネットワークの一覧がアドバタイズされます。第三者がこのプローブ要求を監視して、優先するワイヤレスネットワークと一致する名前を使用してワイヤレスネットワークを構成する可能性があります。ワイヤレスネットワークがセキュリティ保護されていない場合、そのネットワークでは権限のないユーザーがコンピュータに接続できる可能性があります。

  ワイヤレスクライアント更新プログラムをインストールすると、ワイヤレスネットワークを、ブロードキャストネットワークとして構成することも、ブロードキャスト非対応のネットワークとして構成することもできます。また、ワイヤレスの自動構成機能では、ブロードキャスト非対応のネットワークについてのみプローブ要求が送信されます。

  Windows XP でワイヤレスネットワークを構成する際、ワイヤレスネットワークのプロパティダイアログボックスの [アソシエーション] タブを使用して、ワイヤレスネットワークをブロードキャスト非対応のネットワークとして指定することができます。ワイヤレスネットワークをブロードキャスト非対応のネットワークとして定義するには、[ネットワーク名 (SSID)] の下の [Connect even if the network is not broadcasting] をクリックします。（略）

この更新プログラムは、セキュリティの更新としては配布されていないようなので、Windows Updateを自動で運用しているだけではインストールされていないようだ。

早速これをインストールしてみた。

ワイヤレスネットワークの設定にある「優先ネットワーク」のところ（図3左）で、「自動」となっているアクセスポイントを選び、「プロパティ」ボタンを押したときに、図3右の画面が出るようになった。

図3: 更新モジュール導入後における「優先ネットワーク」の「プロパティ」

新たに、「このネットワークがブロードキャストしていない場合でも接続する」のチェックボックスが出るようになっている。

これをオフに設定しておけばよい（チェックを外す）。デフォルトではオンなので注意したい。

これをオフに設定変更して、再び、無線LAN管理用ソフトウェアで傍受して確認してみたところ、たしかに、そのネットワークのSSIDが記載されたprobe requestは出なくなったようだ。

他の自動接続設定のネットワークも全部そこをオフに設定したところ、SSIDが空のprobe requestだけが観測されるようになった。ただし、そのネットワークに接続中は、そのSSIDに対するprobe requestが出てしまうようだ。接続を切断すると出なくなった。どこにも接続していないときは、SSIDが空のprobe requestだけが観測される（図4）。

図4: SSIDが空のprobe request

なお、「このネットワークがブロードキャストしていない場合でも接続する」をオフに設定した場合、そのアクセスポイントが、いわゆる「SSIDステルス」の設定、かつ、「ANYプローブ応答禁止」の設定になっていると、接続できなくなると思われるので注意が必要そうだ。設定項目の名称にある「ブロードキャストしていない」ネットワークとはそういう意味なのだろう*1。

アクセスポイント側でSSIDをいくら隠そうとしてもどのみち正規接続者の接続時には判明してしまうので、「ANYプローブ応答禁止」設定はやめたほうがよいのではないか。公開してもかまわないような名前のSSIDを設定しておくのがよい。

なお、Mac OSやその他の無線LAN対応機器がどうなっているかはまだ確認していない。

Windowsの無線LANが放送するSSIDからPlaceEngineで自宅の場所を特定される恐れ

ここで極めて重大なことに気づいた。

もし、自宅の無線LANアクセスポイントのSSIDが、無線側MACアドレスと同一、ないしその連番、ないし、それを一部に含むものである場合、家でそれに接続するのに使用したことのあるノートPCを、家の外で無線LANの電源を入れていると、その近くに居る人は、probe requestとして放送されるSSIDを傍受することができるので、傍受したSSIDを元に、その人の自宅無線LANアクセスポイントのMACアドレスを推定し、それを元にPlaceEngineを使って自宅の場所を突き止めることができてしまう。

ギャーこれはヤバい。

もう一度簡潔に言う。

たとえば、自宅にソニーのロケーションフリー（以下「ロケフリ」）を設置しているとしよう。ロケフリを設置するとデフォルトで無線LANアクセスポイントになる。

WindowsのノートPCを、そのアクセスポイントに無線LANで接続したことが一度でもあると、図3のようにロケフリのSSIDが「自動」設定で登録されていることがある。

その場合、そのノートPCは、実は、「LocationFree.0013A9XXXXXX」というSSIDを常時（自宅の外で使っているときでも）周囲に放送している。そして、それは誰でも傍受できる（図5）。

図5: WindowsノートPCが自宅ロケフリのSSIDを無線LANで周囲に放送している様子

傍受されたSSIDの「0013A9XXXXXX」の部分は、そのロケフリの無線側MACアドレスなので、10月21日の日記「デイリーポータルZ 記者の家を探しに行く」で書いたように、最近広まりつつある「PlaceEngine」というサービスを使うことで、自宅の位置を調べられてしまう。

もっと簡単に言うと、（自宅の無線LANアクセスポイントの設定によっては）ノートPCを持ち歩いていると、近くに居る人に自宅の場所を知られてしまう場合があるということ。

対策は次の通り。

対策(1)

まず、自宅の無線LANアクセスポイントのSSIDを確認しよう。MACアドレスのようなものが含まれていないか確認する。含まれているなら、アクセスポイントの設定で、SSIDを別の文字列に変更する。

ソニーのロケーションフリーを使用している人は全員モロに該当する。ロケフリのベースステーションを無線LANアクセスポイントとして設置している（デフォルト設定）場合、SSIDの値は「LocationFree.0013A9XXXXXX」の形式で無線側MACアドレスが含まれる（デフォルト設定）。

アップルコンピュータ製の無線LANアクセスポイントも該当する。図5のように「Apple Network XXXXXX」というSSIDがデフォルト設定の製品が出回っているようだ。16進数12桁のMACアドレスのうち下位の6桁しかSSIDに使われていないが、図6のように、上位6桁はベンダーIDなので数種類に限定されているため、何分の一かの確率で自宅特定に使われてしまう。

図6: アップルコンピュータ製アクセスポイントのSSIDとMACアドレス

その他、少なくとも、バッファローの製品、コレガの製品などでは、10月21日の日記「デイリーポータルZ 記者の家を探しに行く」に書いたように、無線側MACアドレスそのものをSSIDにしているものや、1番違いのものを使用しているアクセスポイントもかなり出回っているようなので、該当するかどうかよくわからなくても、とにかく、16進数12桁を含むようなSSID（図7の矢印）は、全く関係のない文字列に変更した方がよい。

図7: 16進数12桁を含むようなSSIDの例
（デイリーポータルZの記事「無線LANを探しに行く」より）

「YBBUser」とか「BBUser」とか「default」といった名前は明らかに該当しないので、むしろこれらを設定する方が安全だ*2（WPAで暗号化の設定をしているならば）。

アクセスポイントのSSIDを変更したら、Windows側で、変更前のSSIDで登録されている自動接続の設定を削除しておく（この作業が重要）。つまり、図8の左の「優先ネットワーク」と書かれたリストの中から、変更前のSSIDの項目を選んで「削除」ボタンを押す。

以上を実施した場合は、以下の対策(2)は必要ではない。上記に該当するSSIDの場合で、もしそのSSIDを変更することができないならば、以下の対策(2)が必要となる。

対策(2)

自宅のアクセスポイントに接続したことのあるノートPCの設定で、自動接続になっている自宅アクセスポイントについて、「このネットワークがブロードキャストしていない場合でも接続する」の項目をオフに設定する（図8）。

この設定項目は、標準状態のWindows XP SP 2には存在しないので、マイクロソフトの「Windows XP Service Pack 2 用のワイヤレスクライアント更新プログラムについて」に置かれている更新モジュールをインストールしてから図8の設定を行う。

図8: 「このネットワークがブロードキャストしていない場合でも接続する」をオフに設定

ついでに、不要な「（自動）」設定の項目は「削除」ボタンで削除してしまったほうがよい。

また、今後、新たなWindowsのノートPCを購入したときにも、そのネットワークに接続すると、デフォルトで「自動」となり、「このネットワークがブロードキャストしていない場合でも接続する」がオンとなるので、オフに設定しなおす。

それが面倒、あるいは、きちんと設定できるか不安な場合は、前述の対策(1)をとった方がよい。

対策(3)

PlaceEngineのデータベースに自宅の無線LANアクセスポイントが登録されないようにすればよいわけだが、現状ではそれは不可能。

「こんなよくわからない手間をかけさせられるのは承服しがたい」という場合には、そもそもPlaceEngine（と同様のサービス）が存在しなければこんなことにはならないことから、「PlaceEngineはプライバシーの侵害である」、「私の家のMACアドレスを勝手に登録しないようにしてください」と運営会社に抗議することも、何らかの解決につながるかもしれない。

電波法59条について再び

なお、他人の無線LANを傍受して知った情報を元に、その存在や内容を漏らしたり、それを窃用する行為（たとえばストーカー行為に利用する等）は、電波法59条違反となる可能性があるので注意。

ただし、無線LANクライアントがprobe requestとしてブロードキャスト（不特定多数に放送）する信号は、電波法59条の「特定の相手方に対して行われる無線通信」に当たらないと解釈される場合には、そのような行為を電波法で取り締まることはできないのかもしれないので、安心はできない。

つまり、PlaceEngineが合法と解釈されるなら、probe request傍受に基づく行為も合法となり、逆に、probe request傍受で得た情報の窃用が違法だというのなら、PlaceEngineも違法と言わざるを得ない。

関連

• PlaceEngineのプライバシー懸念を考える, 2007年5月27日の日記
• ユビキタス社会の歩き方(2) ストーカーから逃れて転居したら無線LANを買い換える, 2007年8月18日の日記
• デイリーポータルZ 記者の家を探しに行く, 2007年10月21日の日記
• ユビキタス社会の歩き方(3) 無線LANのSSIDを不用意に明かさない, 2007年10月21日の日記
• 自分の無線LANがPlaceEngineに登録されていないか確認する方法, 2007年10月27日の日記
• 無線LANのステルス機能ではPlaceEngineに登録されるのを阻止できない, 2007年10月27日の日記
• ユビキタス社会の歩き方(4) 他人から貰う無線LAN機器に警戒する, 2007年10月27日の日記

さて、これから出勤……。

■ 位置特定につながるSSIDの割合は約17% （東海道新幹線沿線2007年8月調べ）

昨日の日記に書いた件、実際に、無線側MACアドレスを割り出されそうなSSIDがどのくらいの割合で存在しているのか気になったので、10月21日の日記の図1〜3で使用したデータを基に集計してみた。

このデータは、今年8月に東海道新幹線で名古屋から品川まで移動した際に、車中でNetwork Stumblerを稼動させてビーコン信号を検出したもので、全部で1760個のアクセスポイントがあった。

そのうち、9.7% は、ビーコン信号にSSIDを載せない、いわゆる「ステルス」設定のアクセスポイントで、これは実際にどんなSSIDが設定されているか不明であるため、次の集計から除外した。

なお、アクセスポイントをステルス設定にしていても、それに接続したことのあるWindows XPの無線LANクライアントは、そのSSIDをprobe requestとして放送してしまうので、ステルスにしていない場合と同様の注意が必要である。

ステルス設定でなかった90.3%の内訳を、以下の5種類に分類してそれぞれの割合を図1の右の円グラフに示す。

1. MACアドレスと同一、連番、及びそれを含むもの
2. MACアドレスっぽいが無関係っぽいもの
3. AOSSで設定したらしき16進数32桁
4. 著名なデフォルト固定名
5. その他の固定名

図1: 観測されたSSIDの種類とその割合

16.9% が、無線側のMACアドレスと同一、ないしその連番、またはそれらを含む文字列、あるいは、下位6桁が含まれていて上位6桁が容易に予想できるものであった。その具体的な内訳を表1に示す。

これらは位置特定につながる。

次に、20.7% は、MACアドレスのような16進数12桁や、MACアドレスの下位6桁のような文字列を含むものであるが、実際の無線側MACアドレスとは全く異なる値のものであった。WAN側のMACアドレスまたはその一部ではないかと考えられる。具体的な内訳を表2に示す。

おそらく、これらから無線側MACアドレスを特定されることはないと思うが、保証はない。もし規則的に割り当てられているなら、その規則が判明してしまうと特定されてしまうかもしれない。

次に、22.5% は、16進数32桁のSSIDであった。これはおそらくAOSSで自動設定されたものであろう。AOSSがどのようにしてこの文字列を生成しているのか知らない。乱数で生成しているなら、そこから無線側MACアドレスを特定されることはないだろうが、もし何らかの規則性があるとすると、それも定かでない。

16.7% は、よく目にするデフォルト設定の文字列だった。残る「その他」の 23.1% は、設置者が独自に設定した名前（またはマイナーな製品のデフォルト設定）である。これらからMACアドレスを推定されることはない。

余談だが、せっかくなので、デフォルト設定名別の割合を表3に示しておく。

■ 「違法性が怖くてイノベーションができるか」？ 著作権法と電波法の場合

明日は情報ネットワーク法学会の大会ということで今夜は新潟に来ている。

「違法性が怖くてイノベーションができるか」と誰か言ったか知らないが、著作権をめぐる昨今の議論を聞いていると、そんな声が聞こえてくるような気がする。つまり、著作権法を厳格に守るだけの遵法精神を固持していたら、このインターネットがもたらした新しい時代に技術革新など生まれない。世界から取り残されてしまう。法律の方が変わるべきなんだ……と。これが一般化して、「法的にグレーな領域に挑戦していかないと新しいことはできないよ」という考え方をしている人がいるかもしれない。

著作権法に対してのそれはまあわからなくもない。さすがに、業務上過失致死傷のリスクを自覚してまでイノベーションを求めようとは誰もしないだろうが、著作権くらいまあいいじゃないかと。では、電波法59条はどうだろうか。

著作権法について「まあいいじゃないか」と思えてしまうのは、所詮、侵害が起きてもお金で解決して後戻りできる話と思えるからではないだろうか。だが、電波法59条の「秘密の保護」はどうだろう？ そういうものだろうか？

電波法59条の規定は古すぎるのだろうか？ 今の時代そしてこれからのユビキタス社会に合わせて、改正されるべきものなのだろうか？ それとも普遍的なものだろうか。よくわからない。法律の専門家の先生方のご意見をいろいろ伺ってみたい。

■ PlaceEngineの落とし所について考えてみる

もし、自分の家のアクセスポイントがPlaceEngineに登録されるのを嫌う人が、現に登録されてしまっている事態に気づいたとき、PlaceEngineの運営会社に対して、登録を削除するよう、また、今後も永久に登録しないよう求めたら何が起きるだろうか。個別に対応してそれで終わりになるだろうか。それとも裁判沙汰になるだろうか。同じような要求が多数出始めるとどうなるだろうか。

電波法59条に違反するという判断になりそうなとき、利便性と将来性を重視して、法改正も視野に入れた落とし所を探すということになった場合、どういう線引きがあり得るだろうか。

いくつか考えられる対応と、その問題点について考えてみる。

(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応

技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。

PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。

新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。

(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応

技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。

このようなルールが万人に受け入れられるものかどうか不明。

(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応

暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。

しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。

(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応

法的には最も安全な対応。技術的にも、MACアドレスリストを提出してもらうことで対応可能。

実質的には公衆無線LANだけしか登録できなくなり、登録数はごくわずかとなってしまう。

■ AOSSの普及が進むとSSIDで検索されてしまう？

月曜の日記に対して、「何故「 MAC アドレス」に限定するのだろうか？（対象者の生活圏内で）ユニークな SSID ならば全て同じ問題が起こるのでは？」という声があった。

これについては後日書く。（朝になってしまった。寝ないと。）

■ 私的録音録画小委員会中間整理に対する意見

パブコメを出した。この心配は杞憂かもしれないとは思ったが、念のため出しといた方がいいかなと思って個人で出した。

締め切り間際に急いで書いたので、今読むと若干混乱が。「除外」という言葉の使い方が混乱させそう*1なので、その点を訂正したもの（訂正箇所は打ち消し線のある部分）を以下に書いておく。ついでに、補足のため一箇所追記した。

私的録音録画小委員会中間整理に関する意見

提出日： 平成19年11月15日
個人/団体の別： 個人
氏名： 高木 浩光
住所： 東京都（略）
連絡先： （略）

該当ページおよび項目名：
第２節 著作権法第３０条の適用範囲の見直しについて
２ 第３０条の適用範囲から除外することが適当と考えられる利用形態
（１）権利者に著しい経済的不利益を生じさせ、著作物等の通常の利用を妨げる利用形態
pp.103-106

意見：

概要

正当な目的での私的複製が違法となることを避けるために、複製する行為を違法とするのではなく、複製した著作物を「再生」する行為（「録音録画」であれば試聴する行為）を違法とするか、あるいは、当該著作物を「再生」する目的（「録音録画」であれば試聴する目的）で複製する行為を違法とするべきである。

説明

電磁的記録（以下「ファイル」）の形で流通する著作物には、コンピュータウイルス（以下「ウイルス」）が混入していることがある。特に、P2Pネットワークにはそうしたファイルが蔓延しており、それが原因となって、Winny等の利用者が機密情報を流出させる事故が相次いでいる。この被害を減らすためには、P2Pネットワークに流通するウイルスを発見して対応を図ることが必要であり、そのために、P2Pネットワークからファイルをダウンロードして行う調査が必要となっている。

現行法の下では、こうした調査は適法に行うことができる。調査用試料となるファイルの入手には著作物の複製を伴うが、調査の目的においては複製物は「個人的に又は家庭内その他これに準ずる限られた範囲内において」しか使用する必要性がないので、著作権法第30条第1項の規定により、その複製は著作権者の複製権を侵害しないものと解されてきた。（Winny等では、ダウンロードする操作が同時に送信可能化をもたらす仕組みとなっているため、そのままWinnyを使用する方法では調査を適法に行うことができないが、送信可能化を伴わずにダウンロードのみを実行する技術を開発することにより、ウイルス対策は適法に行われているところである。）

しかしながら、本件私的録音録画小委員会中間整理の打ち出した著作権法見直し案に従って第30条が改正された場合、P2Pネットワークから情を知ってファイルをダウンロードすることが違法とされることから、ウイルス発見の調査を適法に行うことが不可能となるおそれがあると考える。（一部のP2Pネットワークにおいては、その流通するファイルの大半が違法に送信可能化されているものと指摘されているので、そこからファイルを無作為に入手する行為が「情を知って」複製する行為とみなされてしまう。）

著作権者らも、自らの著作物が違法に送信可能化されていないかを確認するために、ファイルをダウンロードして複製する必要があるであろう。その際に、他人の著作物を無断で複製することが生じ得るが、この行為は正当業務行為として違法性が阻却されると考えられることから、第30条の改正において、それを「正当な目的の複製」として明文で除外する[訂正]明文で除外規定から除外する必要はないと判断される可能性がある。その場合に、著作権とは関係のない、ウイルス対策や情報漏洩対策のためのダウンロード行為が、正当業務行為とみなされるかは定かでないと考える。

これに配慮し、第30条の改正において、正当な目的の類型を列挙して除外する[訂正]除外規定から除外するという案も考えられるが、除外が必要な「正当な目的」の全てを列挙することは困難と考えられる。

他方、複製された著作物も、それが「再生」（「録音録画」であれば試聴）されることがないならば、[追記]（現行法の私的使用である限り）著作権者の権利が侵害されることはないと考える。

したがって、複製する行為自体を違法とする必要はなく、また、複製する行為自体を違法とするのは有害（ウイルス対策や情報漏洩対策を困難にするという新たな危険を社会にもたらすもの）であり、著作権者の権利を保護するには、複製した著作物を「再生」する行為（「録音録画」であれば試聴する行為）を違法とするか、あるいは、当該著作物を「再生」する目的（「録音録画」であれば試聴する目的）で複製する行為を違法とすれば足りると考える。

なお、この意見は、私的録音録画小委員会の趣旨に沿って第30条を改正することにした場合に少なくとも配慮するべきと考える事項を述べたものであり、私的録音録画小委員会の趣旨に沿って第30条を改正することに賛成するものではない。

以上

以前からWinnyの話題の中で書いてきたことだが、日本では送信可能化権を整備して早い時期から違法な公衆送信を強く取り締まったことが、Winnyという怪物の誕生を必然のものにしてしまった。その結果、著作物は相変わらず保護されないばかりか、流出した秘密情報が回収不能となるという新たな危険を社会に生み出すことになった。

次のステップとして「ダウンロードの違法化」が安直に進められれば、加えて、ウイルスに対抗することも許されず、情報流出の事実確認さえ許されないという世の中になっていってしまいやしないだろうか。

なお、意見の最後でも述べているように、これは第30条の改正に賛成する前提での意見ではなく、「どうしてもそうすることになるなら最低限考慮して欲しいこと」を述べたものだ。ここでは、最低ラインとして、試聴する行為または試聴する目的で複製する行為を示したが、さらに緩めて、反復して試聴する行為または反復して試聴する目的で複製する行為というラインを提案するのでもよかったかもしれない。

■ こんな銀行は嫌だ

「こんな銀行は嫌だ――オレオレ証明書で問題ありませんと言う銀行」……そんな冗談のような話がとうとう現実になってしまった。しかも、Microsoftが対抗策を施した IE 7 に対してさえ言ってのけるという。

この原因は、地方銀行のベンダー丸投げ体質と、劣悪ベンダーが排除されないという組織の構造的欠陥にあると推察する。

図1: 武蔵野銀行の「法人のお客さま」のページで
「ログインはこちら」としてリンクされているページに現時点でも書かれている内容

【ぶぎんビジネス情報サイト】アクセス時に表示される警告メッセージについて

ぶぎんビジネス情報サイトでは、サイトＵＲＬ（https://www.bugin.cns-jp.com/）ではなく、ベースドメイン（https://www.cns-jp.com/）でSSLサーバ証明書を取得しております。このため、本サイトにアクセスする際、ブラウザの仕様により次の警告メッセージが表示されますが、セキュリティ上の問題はございませんので、安心してぶぎんビジネス情報サイトをご利用ください。

（略）

左図の画面（ページ）が表示されましたら、「このサイトの閲覧を続行する（推奨されません）」を選択(クリック)してください。ぶぎんビジネス情報サイトのログイン画面に遷移します。

IE7.0で本サイトにアクセスされますと、アドレスバーの背景色が赤くなり、「認証エラー」と表示されますが、これは、SSLサーバ証明書をサイトURLベースドメイン（https://www.cns-jp.com/）で取得しているためです。サイト自体はSSL128bitによる暗号化通信を行っておりますので、セキュリティ上の問題はございません。

武蔵野銀行「【ぶぎんビジネス情報サイト】アクセス時に表示される警告メッセージについて」より

図2: 北越銀行の「ホクギンeビジネス」のページと
そこから「アクセス時に表示される警告メッセージについて」としてリンクされているページに現時点でも書かれている内容

【法人向け情報Web　ホクギンeビジネス】アクセス時に表示される警告メッセージについて

法人向け情報Webホクギンeビジネスでは、サイトＵＲＬ（https://www.hokuetsu.cns-jp.com/）ではなく、ベースドメイン（https://www.cns-jp.com/）でＳＳＬサーバ証明書を取得しております。このため、本サイトにアクセスする際、ブラウザの仕様により次の警告メッセージが表示されますが、セキュリティ上の問題はございませんので、安心して法人向け情報Web　ホクギンeビジネスをご利用ください。

（略）

＜InternetExplorer7.0をご利用の場合＞

以下の画面（ページ）が表示されましたら、「このサイトの閲覧を続行する（推奨されません）」を選択(クリック)してください。法人向け情報Web　ホクギンeビジネスのログイン画面に遷移します。

IE7.0で本サイトにアクセスされますと、アドレスバーの背景色が赤くなり、「認証エラー」と表示されますが、これは、ＳＳＬサーバ証明書をサイトＵＲＬベースドメイン（https://www.cns-jp.com/）で取得しているためです。サイト自体はSSL128bitによる暗号化通信を行っておりますので、セキュリティ上の問題はございません。

北越銀行「【法人向け情報Web　ホクギンeビジネス】アクセス時に表示される警告メッセージについて」より

「オレオレ証明書」についておさらいしておくと、こうした警告を「問題ありません」と説明する出鱈目が、3年ほど前に地方自治体を中心に流行しかけたが、「オレオレ証明書」という用語が誕生して、多くの人が「問題ないわけがない」ということを認知するようになった。

• 広島市曰く「警告は出ますがセキュリティ自体には問題ない」, 2005年1月11日の日記
• 小学生にセキュリティ警告を無視させる埼玉県, 2005年1月14日の日記
• 2005年1月15日の日記

  11日の日記 に対して、「昨日自分で書いた『オレオレ証明書』という言い方が気に入ってきた」というトラックバック を頂いた。「オレオレ証明書」……ソレダ！ 使わせて頂く。

• 日経サイエンスに「オレオレ証明書」, 2005年3月1日

  日経サイエンス2005年4月号にナイスな記事が載っていた。

  自治体が促進!? ネットの「オレオレ詐欺」
  役所が進める電子政府の安全確保が，かえって利用者を危険に追い込む

  （略）情報セキュリティの技術者たちはこういうニセ証明書を“オレオレ証明書” と呼ぶ。（略）自治体を名乗って「ブラウザーの警告なんか無視してくれ」というのがオレオレ証明書だ。（略）

• 銀行業界が自治体に苦情を申し立てても不思議でない, 2005年3月15日

  そもそも、この警告が出たら「いいえ」を押すのが当然の常識として人々にもともと理解されているはずのところが、昨今では、その常識が崩れつつある。その原因は、自治体の電子申請システムだ。自治体の愚かな行いが、銀行に対するphishing攻撃の危険性を増大させている。

  そもそもWebのサーバ証明書は、Webというグローバルなアプリケーションドメインに対して設定されたそれ固有のPKIモデルで稼動しているものであり、銀行をはじめとする事業者たちはこれまで、そのモデルのルールに則って証明書を購入し運用してきた。そこへ、後からやってきた役所の連中が、そのモデルのルールを無視し、勝手認証局を立て、「私達も仲間ですよ」と利用者達をたぶらかしている。（ブラウザベンダーに対して「仲間に入れて」とお願いするのではなしに。）

  銀行業界は、このような自治体の迷惑行為に対して、やめてもらえないかと、要請してはどうか。

民間企業だったらこんなことはしない。なぜなら、他を見回してみたときにそんなことをやっているところはないと気づくからだ。一般に、誰もやらないことを自分がやろうとするときは、何か間違っているのではないかと疑ってみるのは猿でもすることだ。それなのに、自分だけはそれをやっても許されると思ってしまうのは、役所ならではだろう。

その後、Microsoftがこれに対抗策を打ち出して、Internet Explorer 7 ではより強力なエラー表示が出るように改善された（図3）。

図3: SSL接続の異常を示すIEの画面（上はIE 6の場合、下はIE 7の場合）

IE 6では、単純な警告ダイアログが出て「はい」か「いいえ」のボタンを押すだけになっており、ひとたび「はい」を押してしまうと、その先では何の異常もなかったかのようにアクセスできてしまうため、意味もわからず「はい」を押してしまう人が続出していた。

これが IE 7では、図3のように、「詐欺や、お使いのコンピュータからサーバーに送信される情報を盗み取る意図が示唆されている場合があります」ときちんと理由を示した警告文に改善されたうえ、「サイトの閲覧を続行しないことを推奨します」とまで書かれている。それでもなお、「このサイトの閲覧を続行する」という選択肢が残されているものの、「（推奨されません）」とまで書かれている。万が一これが続行された場合でも、次の図4のように、続行した先のページでは常時、異常であることを示す表示（アドレスバーが赤くなり、「証明書エラー」と出る）がなされるようになった。

図4: IE 7で警告を無視して続行した場合の画面

ここまでしつこく異常を伝えるように改善されたのだから、IE 7（とそれが標準搭載されるWindows Vista）が普及するにつれて、このオレオレ証明書問題は自然と解決されていくだろうと思っていた*1。

ところが、実際にIE 7が普及してきた現在、これらに対してさえ、「問題ありません」だとか、「『推奨されません』をクリックしてください」と言う虫*2が沸いてきた。しかも、よりによって銀行がそれを言うのである。

フィッシング詐欺の脅威が迫っている中、「アドレスバーが赤くなって『エラー』と表示されていたら閲覧を中止しなければならない」という鉄則を利用者の常識としなければならないところに、「使ってもいい場合がある」などという嘘*3が吹聴されたら、対策が台無しであり、皆が迷惑する。

銀行に脆弱性があって放置されているとか、銀行が改竄されているとか、そういうのはある意味自業自得なのだから、周りからとやかく言われる筋合いはないと言われるかもしれないが、このような、嘘の説明を言いふらす行為は、他のまじめにやっている銀行が迷惑するだろう。金融庁が指導するか、あるいは、全銀協がこれらの銀行に対して抗議するべき事態と言える。

それにしても、なぜこんなことになってしまっているのか。2つの銀行の説明文を見ると、それらが同一の文章から作られていることがわかる。単にこの2つの銀行が馬鹿だというだけでなく、他に汚染源があると推察される。

そこで、11月2日にこれらの銀行に電話して、問題点を指摘するのと同時に、原因を探るべく取材を試みた。*4

まず、電話すると先方は第一声として、「証明書を買うかどうか検討している最中でして」と言う。話を聞くと、今年の7月に地銀ネットワークサービス株式会社から文書で通達があり、証明書を買えば警告が出なくなるとの説明を受けているという。

「地銀ネットワークサービス株式会社」とは全国地方銀行協会に加盟する全国の地方銀行が株主となって設立された共同事業会社であり、ここが「cns-jp.com」というサイトを運営している。図1、図2のエラー画面が出るWebページは、「www.bugin.cns-jp.com」と「www.hokuetsu.cns-jp.com」であるように、この「cns-jp.com」の配下にある。つまり、共同運営会社がASPサービスとしてこれらのサイトを提供しているわけである。

同じこのASPを使う銀行でも、この警告が出ないところもある。たとえば、沖縄銀行向けの「https://www.okinawa.cns-jp.com/」では警告が出ない。2006月9月12日の日記の記録では、沖縄銀行のこのページも警告が出る状態だったので、その後、沖縄銀行は証明書代金を支払ったのだろう。現在でも、以下の7つの銀行が警告が出る状態のままとなっている。

• https://www.hokkoku.cns-jp.com/
• https://www.hokuriku.cns-jp.com/
• https://www.oitabank.cns-jp.com/
• https://www.hokuetsu.cns-jp.com/
• https://www.iyo.cns-jp.com/
• https://www.shinwabank.cns-jp.com/
• https://www.bugin.cns-jp.com/

なぜこれだけの長期間にわたって、「買うかどうか検討している最中」のままなのか謎であるわけだが、それは理解できなくもない。なぜなら、銀行が証明書を取得するのではないからだ。

沖縄銀行用のサイト「www.okinawa.cns-jp.com」の証明書の発行先を見ると次のようになっている。

CN = www.okinawa.cns-jp.com
OU = Operations
O = CNS
L = Chiyodaku
S = Tokyo
C = JP

そもそも「CNS」などという名前で証明書が取れること自体も異常（会社の英文名称で取るのが普通）*5だが、「CNS」とは「Chigin Netowrk Service Co., Ltd.」のことのようだ。

このように、沖縄銀行が証明書を取得したのではなく、証明書の取得者はASP提供会社である地銀ネットワークサービスになっている。それは当然で、ドメイン名が「cns-jp.com」だからだ。

つまり、証明書の取得にお金が必要というのは、システムの都合であって、銀行が証明書を買うという話ではない。実際、システム設計を変更すれば、各銀行ごとにばらばらに何枚も証明書を買う必要などない。たとえば、次のURLにすれば「www.cns-jp.com」用の証明書1枚で済む。*6

https://www.cns-jp.com/hokkoku/
https://www.cns-jp.com/hokuriku/
https://www.cns-jp.com/oitabank/
https://www.cns-jp.com/hokuetsu/
https://www.cns-jp.com/iyo/
https://www.cns-jp.com/shinwabank/
https://www.cns-jp.com/bugin/

はじめからこのようにしなかったシステムの設計ミスであろう。*7

システムを作った際、SSLのことを何も考えなかった結果だ。そしていざサービスを始めてみると、SSLで警告が出るという苦情が寄せられるようになり、さてどうするかというときに、システムの欠陥を直すのではなしに、証明書を無駄に何枚も買わせて解決しようとしたわけだ。

これはシステムの設計ミスが原因なのだから、その解決に必要な費用はシステム提供者である地銀ネットワークサービスが負担するべきものだろう。それを銀行に支払いを要求しているものだから、各銀行も、意味のわからない料金を払うわけにいかないという状態になっていると思われる。

このことについては、12日に地銀ネットワークサービスにも電話して指摘した。しかし、どうもこの会社には誰もこの件についての責任者がいないようなのだ。電話で用件を伝えようとすると、用件を文書で書いて送れという。なんでわざわざ文書で書かないといけないのかと尋ねると、システムの開発を外部に出しているので、外注先に指摘の文書を見せたいのだという。

つまり、何もかもが業者に丸投げで、自力で考える頭が存在していない。

そうなると、外注の業者が自らの失敗を認めるはずがない。「このままで問題ありません」と回答することになる。「問題ありません」という回答が、地銀ネットワークサービスの案山子を素通りして、各地方銀行に配布される。そして図1と図2のような出鱈目な説明が表に出てくる。

馬鹿ばかりだ。誰一人、責任を持って自力で考えられる人がそこにはいない。これは技術がわからないからとかいった話ではない。他所がどうしているか見て廻れば異常だと感づけることであるし、外注業者を信用してはならないことは当たり前の話だ。

どこの糞業者を使っているのか聞き出したかったが、残念ながら教えてもらえなかった。

ちなみに、この問題は、システムを改修しなくても簡単に解決できる別の方法がある。「ワイルドカード証明書」を使えばよいだけの話だ。ワイルドカード証明書とは、サーバ証明書の発行先のCommon Name（ホスト名）を「*.cns-jp.com」という「*.」を使った名前で登録するもので、これにより、同じドメイン上のどのホストにも正しく適用できるというものだ。

ワイルドカード証明書を導入すれば一瞬で解決するし、沖縄銀行も変な別料金を負担する必要はなかった。外注先業者はそれを知らない無能業者であるか、もしかすると、知らないふりをして、無駄に証明書を買わせ、証明書取得代行の手数料で儲けようと鴨を待ち構えている可能性だってある。

なお、出鱈目な説明を掲示している2つの銀行には以下の点を伝えた。

1. 「セキュリティ上の問題がない」というのは嘘偽りである。
2. 証明書を買うように言われているのもおかしな話、買うのは地銀ネットワークサービスであり、あなたの銀行ではない。
3. 本来、追加の料金負担など必要ない。地銀ネットワークサービスが設計ミスを直すべき話。
4. あなた方が地銀ネットワークサービスに抗議するべき話。
5. 修正に時間がかかるにしても、とりあえずまず、この誤った説明文を即刻、削除するべき。
6. 削除するだけで済まされる話ではない。今まで間違った説明をしていたことを告知し、正しい使い方「赤くなっていたら使用を中止する」を周知するべき。

特に重要なのは、誤った説明を削除するという件だ。北越銀行には11月2日に説明を終え、武蔵野銀行には11月12日に説明を終え、どちらの担当者も意味を理解して納得していたが、どちらの銀行も、今もなおこの出鱈目な説明を利用者に読ませ続けている。

追記

さすがに、IE 7 になってから「問題ありません」と説明するところはほとんど見当たらなくなった。しかし、大学はあいかわらずひどい。こういう大学で教育を受けた卒業生が将来の糞業者になっていくのだろう。高校生諸君はこれらの大学は避けたほうがいい。

• 関西大学, 授業支援システム

  SSL対応ページでは証明書のエラーが表示されることがありますが，問題はございません．

  2.「このサイトの閲覧を続行する (推奨されません)。」のリンクを選択する．

• 山形大学, 学術情報基盤センター

  現在、WebMailに接続すると、”この Web サイトのセキュリティ証明書には問題があります。”というページが表示される、あるいは、”セキュリティの警告”というウィンドウが表示される場合があります。

  これは、システム移行にともなう、証明書の手続きが間に合っていないためで、セキュリティ上の問題はありません。

  ページが表示された場合は、”このサイトの閲覧を続行する (推奨されません)。 ”をクリックしてください。

• 岐阜大学, 総合情報メディアセンター

  URLをクリックして「Web サイトのセキュリティ証明書には問題があります」のページが表示された場合は（学内のサーバですので問題ありませんので），「このサイトの閲覧を続行する (推奨されません)」をクリックしてください。

• 久留米大学, 情報教育センター

  Internet Explorer 7をインストール（アップグレード）後、学内ページの一部を開こうとすると、下のエラーが表示されるようになりますが、「このサイトの閲覧を続行する（推奨されません）。」をクリックすると通常の画面が表示されますのでそのままご利用ください。

  利用中は下の図のようにURL欄の背景がピンクになり「証明書のエラー」と表示されます。

• 専修大学, Ｗｅｂ履修登録

  「証明書に関するセキュリティの警告」が表示されますので、「はい」や「このサイトの閲覧を続行する」をクリックしてください。

追記（23日）

上で引用した専修大学のページは 404 Not Found になったのだが、これに関して、専修大学の方々から2通のメールを頂いた。事務計算センターの方から頂いた「一個人として専修大学の現状及び取り組みを知っていただきたい」「大学からの正式な見解を説明するものではない」というご趣旨のメールによると、平成19年度の履修登録ではたしかにオレオレ警告を無視させていたが、「セキュリティに対する認識の甘さについては反省をし、早急に改善すべき課題としてとらえ、改善への対応・対策を既に実施しています」とのことで、10月1日の大学全体のリニューアルの際に、オレオレ警告の出るSSLサーバは撤廃しているのだそうだ。Web履修登録については、平成19年度はもう終わっているので、平成20年度に向けてシステムの開発作業を計画中とのこと。

続けて専修大学教務部教務課の方から、「昨日、本学のシステム担当者からも連絡をしておりますが」との前提を置いた形で以下の通告を受けた。

Subject: 11/17：高木浩光＠自宅の日記「「こんな銀行は嫌だ」」に関する記載内容について

今回、貴殿が書かれた標記の日記の中で、本学のＷｅｂ履修登録システムに関する記載事項がありました。昨日、本学のシステム担当者からも連絡をしておりますが、今回運用担当者として連絡をさせていただきました。

本学としましては、貴殿のご指摘のとおり、このセキュリティへの甘さについては認識をしており、平成２０年度のシステム稼動より対策を講じる手続きを既に行っておりました。

なお、貴殿が書かれたこの記載事項によって本学を希望する受験生等への影響が考えられます。ご指摘内容については真摯に受け止めており対策を行ってまいりますので、本学の記載内容をＨＰ上から削除していただければ幸いです。

以上

このようなご心配を招くのであれば、上のような中途半端な引用で済まさず、正確に事実関係を伝えなくてはいけないと思う。

上の「専修大学, Ｗｅｂ履修登録」のリンク先は、17日の時点では以下の内容になっていた。

図5: 「専修大学, Ｗｅｂ履修登録」のページに2007年11月17日の時点で書かれていた内容（現在は削除）

「セキュリティについて」の部分に書かれている内容から、学外から使用することを前提としたシステムだったことがわかる。そして、「「証明書に関するセキュリティの警告」が表示されますので、「はい」や「このサイトの閲覧を続行する」をクリックしてください。」と書かれていた。

上の他の事例とは異なり、「問題ありませんので」といった説明は行われていなかった*8。そして、このページは現在削除されている。

ただ、二部のWeb履修登録のページからはまだ削除されていないようだ。また、ここからリンクされている「操作説明書」(PDF) には次の記載がある。

図6: 専修大学Web履修操作説明書 2007年度版

※ログインボタン押下後、証明書に関するセキュリティの警告が表示される場合がありますので、「はい」や「このサイトの閲覧を続行する」を選択してください。

これによると、ログイン画面に到着したときにオレオレ警告が出る――(a)というのではなく、パスワードを入力してそれを送信しようとボタンを押した瞬間に出るオレオレ警告を無視するように指示していたということのようだ。これは、(a)に比べてより危険性の高い利用手順を教えていたことになる。

一度このような手順に慣れてしまうと、それが普通の使い方だと思い込んでしまうだろう。その誤った理解を矯正しなければ問題は解決したとは言えない。

現在の専修大学 在学生・教員向けポータルサイト（これがそのリニューアルされたシステムだろうか）には、ログイン画面があるが、図7のように、「セキュリティについて」の部分で、従来のWeb履修登録システムにあったのと同じ注意書きがあるものの、警告が出た場合にどう行動するべきかについては何も書かれていない。

図7: 専修大学の「在学生・教員向けポータルサイト」（23日朝現在）

もし、学生がたとえば通学中に道端を歩きながら、iPod touch等を用いて livedoor Wireless経由でこのポータルを利用する際に、ログインしようとパスワードを入れてボタンを押した直後*9、SSLのサーバ証明書に異常があることを示す「オレオレ警告が」出たとしよう。*10

図8: iPod touch におけるオレオレ警告の例

このとき、学生達（19年度のWeb履修登録の体験を経た）は、どちらのボタンを押すだろうか？

つまり、誤った説明を単に削除するのではなしに、これまでに説明していた操作方法は誤った使い方だったという事実、そして、今後もしこのポータルサイトを使う際に警告が出た場合は、絶対に先に進んではいけないことを、周知しなくてはならない。

このことは微力ながら私からも専修大学の在学生諸君にお伝えしたい。（削除するのではなく。）

また、それだけでなく、一般にどこのサイトでもこの警告が出た場合はけっして無視してはいけないものであるという正しいリテラシーを「教育」するのが本来の教育機関の役目であろう。

上に挙げた2つの地方銀行は、今現在も、嘘偽りの説明を掲示したまま顧客に読ませているが、営利企業が嘘偽りの説明を放置するのは、法令違反がない限り、営業上の自由だろう。無かったことにして終わりにする自由もある。

しかし、大学はどうだろうか。

■ オレオレ証明書の区分 第三版

2005年11月18日の日記「オレオレ証明書の区分 改訂版」を改訂する。第六種を変更した。

第一種オレオレ証明書

不特定多数に利用させることを想定していて、ルート証明書もサーバ証明書もインストールさせるつもりのないもの。

第二種オレオレ証明書

不特定多数に利用させることを想定していて、ルート証明書かサーバ証明書をインストールするよう促しているが、インストール方法として安全な手段が用意されていないもの。

第三種オレオレ証明書

不特定多数に利用させることを想定していて、ルート証明書かサーバ証明書をインストールするよう促しており、安全なインストール方法が用意されているもの。

第四種オレオレ証明書

特定の者だけに利用させることを想定しているもの。

第五種オレオレ証明書

正規の認証局から取得したサーバ証明書であるが、一部のクライアントでその認証局がルートとして登録されていないもの。

第六種オレオレ証明書

正規の認証局から取得したサーバ証明書であるが、使い方を誤っているもの。（中間認証局から取得したサーバ証明書なのに、中間認証局の証明書をサーバに設置していないために、クライアントが認証パスを検証できないもの。あるいは、サーバ証明書のホスト名と実際に使用するサーバのホスト名が一致していないものなど。）

■ 続・ユビキタス社会の歩き方(5) Windows以外の無線LAN機器の場合

5日の日記「ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する」の続き。

Windows XPでは、デフォルト設定では、「自動」接続設定されたアクセスポイントの各SSIDを常時ブロードキャスト、つまり周囲に撒き散らしているので、SSIDのプライバシー性が特に重大だった。では、他の無線LAN対応機器はどうか。いくつか調べてみた。

以下の「自宅を特定されない使い方」で、自宅のSSIDの変更が必要かについては、5日の日記と、6日の日記「位置特定につながるSSIDの割合は約17%」を参照。（もちろん、世の中にPlaceEngine（と同様のサービス）が存在しなければ、そんなことにはならないのだが……。）

Mac OS Xの場合（Mac OS 10.4.10 で確認）

挙動

スリープから復帰した直後に（パスワード認証をする前の時点から）、直前に接続していたアクセスポイントのSSIDをprobe requestとして、約10秒間ブロードキャストする。

それに接続できない場合、その前に接続していたSSIDについて同様にブロードキャストする。それに接続できない場合はさらに前に接続していたSSIDについて同様に、と、すべての覚えているSSIDについて続く。

どこかに接続できたらprobe requestのブロードキャストをやめる。

その後、接続が安定している限りprobe requestは送信されないっぽい。

SSIDを出さなくする方法

覚えているSSIDを削除する方法がよくわからない。キーチェインから削除すると消えるっぽい。接続中のSSIDは削除できないっぽい。

しかし、消しても、また接続すると、次にスリープから復帰した時点でブロードキャストされてしまう。

リスクの例

接続できるアクセスポイントのない場所で電源を入れていると、その間、周囲で自宅SSIDを傍受され得る。

接続できるアクセスポイントのある場所（勤務先等）では、自宅から持ってきて最初にスリープから復帰させた際の約10秒間、周囲で自宅SSIDを傍受され得る。

自宅を特定されない使い方

自宅のSSIDを変更できない場合：

自宅を出たら、自宅アクセスポイントから十分離れて接続しなくなった時点で、スリープから復帰させ、キーチェインから当該SSIDを削除してから、目的の場所に向かう。

自宅のSSIDを変更できる場合：

1. 自宅アクセスポイントのSSIDを変更する
2. キーチェインで古いSSIDを削除する（たぶんこれでいい？）

Windows Mobile 5の場合（EN・ONEで確認）

挙動

電源を入れたとき、直前に接続していたアクセスポイントのSSIDをprobe requestとして、約1秒間ブロードキャストする。

それに接続できないときは、過去に接続した各SSIDについて同様にブロードキャストする。

その後も約1分間隔で、同じトライを繰り返す。

どこかに接続できたらprobe requestのブロードキャストをやめる。

SSIDを出さなくする方法

「設定」の「接続」の「ネットワークカード」で、「ワイヤレスネットワークの構成」から、当該SSIDの項目を選択して「メニュー」から「設定の削除」を選ぶ。

リスクの例

接続できるアクセスポイントのない場所で電源を入れていると、その間、周囲で自宅SSIDを傍受され得る。

接続できるアクセスポイントのある場所では、自宅から持ってきて最初に電源を入れた瞬間に、周囲で自宅SSIDを傍受され得る。

自宅を特定されない使い方

自宅のSSIDを変更できない場合：

自宅を出たら、「ワイヤレスネットワークの構成」から自宅SSIDを削除する。

自宅のSSIDを変更できる場合：

1. 自宅アクセスポイントのSSIDを変更する
2. 古いSSIDを「ワイヤレスネットワークの構成」から削除する

myloの場合

挙動

電源を入れ無線LANをオンにしたとき「ワイヤレスLAN接続」で「登録済み」となっている接続先リストの上から順に接続が試みられる。

各接続先について、接続できない間、そのSSIDをprobe requestとして30秒間ほどブロードキャストする。

どこかに接続できたらprobe requestのブロードキャストをやめる。

SSIDを出さなくする方法

「ワイヤレスLAN接続」で「登録済み」から削除する。

リスクの例

電源を入れ無線LANをオンにしたとき、「登録済み」接続先リストの上の方に自宅のSSIDが登録されていると、それへの接続が試行される前に中止しないでいると、その間に周囲で自宅SSIDを傍受され得る。

自宅を特定されない使い方

自宅のSSIDを変更できない場合：

自宅を出たら、「登録済み」接続先リストから自宅SSIDを削除する。

それはあまりに不便なので、自宅SSIDを「登録済み」接続先リストの下の方に設定しておき、上の方に勤務先やその他のアクセスポイントを登録しておき、電源を入れ無線LANをオンにしたときに、自宅への接続が試みられる前に中止する。

自宅のSSIDを変更できる場合：

1. 自宅アクセスポイントのSSIDを変更する
2. 古いSSIDの接続を「登録済み」リストから削除する

PSPの場合（バージョン 3.72で確認）

挙動

電源を入れて「インターネットブラウザ」を起動しどこかへ最初にアクセスするとき、前回接続していたアクセスポイントのSSIDをprobe requestで一瞬だけブロードキャストする。

「ネットワーク接続」画面で「利用する接続を選択してください」と出た場合は、ここで選択した接続先のSSIDを1秒間ほどprobe requestとしてブロードキャストする。

SSIDを出さなくする方法

自動接続をやめる。「インターネットブラウザ」の「ツール」メニューの「設定」で、「接続設定」を選び、「利用する接続」を「自動選択」ではなく「手動選択」に変更する。

リスクの例

「インターネットブラウザ」の接続設定が自動選択になっている場合、電源を入れて「インターネットブラウザ」を起動しどこかへ最初にアクセスするとき、前回接続していたアクセスポイントが自宅だった場合、その瞬間に周囲で自宅SSIDを傍受され得る。

自宅を特定されない使い方

自宅のSSIDを変更できない場合：

「インターネットブラウザ」の「接続設定」で「手動選択」に設定（上記の通り）しておき、アクセス時に出る接続先の選択画面「利用する接続を選択してください」で、自宅SSIDを選ばないように気をつける。

自宅のSSIDを変更できる場合：

1. 自宅アクセスポイントのSSIDを変更する
2. 古いSSIDの接続を「ネットワーク接続」設定のリストから削除する

iPod touchの場合

挙動

電源を入れたとき、前回接続していたアクセスポイントのSSIDをprobe requestとして、一瞬だけブロードキャストする。

それ以降は、そのSSIDでのprobe requestはブロードキャストされない。（電源を切って入れ直しても。）

SSIDを出さなくする方法

どこかで一度電源を入れる。

リスクの例

自宅を出て、どこでも電源を入れず、どこかで最初に電源を入れたとき、その瞬間に周囲で自宅SSIDを傍受され得る。

自宅を特定されない使い方

自宅のSSIDを変更できない場合：

自宅を出たら、自宅アクセスポイントから十分離れて接続しなくなった時点で、一度電源を入れる。

自宅のSSIDを変更できる場合：

1. 自宅アクセスポイントのSSIDを変更する
2. 一度電源を入れる

■ 家庭の無線LANでのSSIDの名付け方

無線LANの「SSID」は、どれが自分の使ってよいアクセスポイントなのかを人間が見分けるための名前でもあるのだから、本来、覚えやすい名前にしておくべきものではないだろうか。

これは、接続の設定をするときだけの話ではなく、今どこにつながっているかを確認する癖を付けるという意味でも重要ではないか。ゲーム機やiPod touchのように持ち運ぶ機器が無線LAN接続をするのが普通になってきたからだ。

昨今の無線LANアクセスポイント製品は、デフォルト設定が覚えられないような番号になっていたりするが、隣の家のSSIDを自分の家のものだと間違えてしまうことがありそうだ。もちろん、逆に、ご近所がみな同じ「YBBUser」というのも困る。

セキュリティの半可通が、「SSIDは予測困難なランダムな文字列にしておくのが常識」などと「キリッ」とした顔で言うかもしれないが、それは無視してよい。WPAによる暗号化さえ正しく設定（これは元々必須）しておけば、SSIDを知られたところでセキュリティ上の問題はない。そもそも、元々SSIDは電波に載って飛んでいるので隠すことは不可能だ（ステルス機能でも隠し切れない）。

SSIDの名前をランダムにしないことに問題があるとすれば、プライバシーの観点からだろう。家庭の無線LANのSSIDにふさわしい名前の要件を列挙すると、こんな感じだろうか。

1. 家族が覚えやすい名前

   例：動物の名前、食べ物の名前、星の名前、芸能人の愛称、子供向けアニメの名前、思い出の旅行先の名前など。

2. ご近所に知られても恥ずかしくない名前 （SSIDはご近所にも見える）

   例：大人向けアニメの名前を避けるなど。

3. ご近所とダブらない名前 （SSIDはご近所にも届く）

   例：メーカー名を避ける。1桁程度の番号を加えるとよいかも。

4. 家の近くを通りすがる人に見られても問題のない名前 （SSIDは通りすがりの人が見る）

   例：興味をそそるような名前を避け、平凡な名前に。子供がいることを知られたくなければ、子供が好きそうなものの名前を避ける。

5. 勤務先の人や知人などに知られても問題のない名前 （接続機器が外出先でSSIDを出す）

   例：自宅の場所や出身地等を知られたくないなら、地名を避ける。

6. 電車内などで赤の他人に知られても問題のない名前 （接続機器が外出先でSSIDを出す）

   例：氏名を知られたくないなら、氏名を避ける。興味をそそるような名前を避け、平凡な名前に。

そして、無線LANクライアント側では、セキュリティの観点から、次の点に注意する。

• 暗号化なしのアクセスポイントに自動接続の設定をしないこと。
• 自分の家のSSIDと同じ名前のアクセスポイントが、暗号化なしで利用可能になっていても、接続しないこと。

うーん、本当にこれでいいのか？

■ iPod touchでオレオレ警告が出たとき「□」ボタンを押してはいけない

このブログも始めて4年半になるが、一昨日、初めていわゆる「削除依頼」を受け取った。というわけで、17日の日記に追記した。

それはともかく、その追記を書いている際に、iPod touch の Safariにセキュリティに関わるバグを発見した。これは、脆弱性と言うこともできるバグではあるが、この事実を公表することにより増大し得る危険性の差分が十分に小さいのに対して、この事実の公表で利用者が自衛できるようになることによる安全性の向上の方が十分に大きいと判断し、以下にこの事実を記す。

iPod touchで https:// のサイトに接続した際、SSLのサーバ証明書の異常を示す警告（通信路上で盗聴等が行われようとしている可能性を示す）が出たとする。ここで「キャンセル」「続ける」のどちらのボタンもタッチせずに、本体下部にある「□」印の物理ボタンを押すと、どうなるか。

図1: iPod touchで「オレオレ警告」時に「□」ボタンを押した様子

「□」ボタンを押すとメニュー画面に戻るので、ここで「Safari」アイコンをタッチすると、直前に表示していたWebサイトが現れるが、ここで、さきほどのリンクをタッチして再び同じ https:// サイトにアクセスしようとしてしまったとする。

すると、本来ならば再び「オレオレ警告」が出なくてはならないのに、警告が出ずに、ページにアクセスしてしまう。（ただし日本語テキストの文字化けすることがあるようだ。）

図2: Safariを起動して同じサイトにアクセスすると警告が出ない様子

したがって、オレオレ警告が出ている最中に「□」ボタンを押してはいけない。もし押してしまったら、その後は同じ https:// サイトへ行かないように注意しなくてはならない。

これは、https:// サイトをブックマークしている場合にも同様に注意が必要だ。ブックマークからいつものログインサイトを選択したときに、もし「オレオレ警告」が出たら「キャンセル」を押さないといけないが、慌てて「□」ボタンを押してしまうと、その後再びブックマークから同じログインサイトへ行ったとき、警告が出ず、盗聴されているのに気づかずにパスワードを送信してしまうという事態が起こり得る*1。

ブラウザを再起動すれば元の状態に戻るが、iPod touchの Safariには終了の機能がないようなので、Safariがクラッシュして落ちるのを待つか、iPod touch自体の電源を完全に切る必要がある。本体上部左にある物理ボタンを長押し（数秒間）して、「電源オフ」の赤スライダを出して、それをスライドさせて切る。（電源を入れるには再び長押しする。）

図7: iPod touchの「電源オフ」機能

脆弱性として扱われるかはわからないが、念のため、IPAの脆弱性届出窓口に届け出て製品開発者に修正を促してみる。

追記（12月8日）

iPod touchで Safariを終了させる機能が存在することをある方からメールで教えていただいた。

Safari使用中に本体下部の「□」ボタンを長押し（5秒ほど）すると、Safariを強制終了させることができるようだ。その後 Safariを使用してみると、上記の方法で再起動したのと同じ状態になった。

■ 思い出のあんかけスパ

名古屋を離れてすっかり忘却していたあの喫茶店のスパゲッティの味。実は「あんかけスパ」と呼ばれる名古屋固有の特殊な料理だと理解したのは数年前。ココイチが「パスタデココ」なる店を始め、虎ノ門に店があると知り、霞ヶ関に用事があった帰りに何回か行っていた。その後、秋葉原へ転勤になると、近くに末広町店があるというので、ランチに嫌がる職場の同僚を引き連れて食べに行っていた。その店が1年前に閉店。閉店を惜しんで買った店頭売りのレトルトソースが、賞味期限切れになっていた。

というわけで食べてみた。本場は 2.2 mm のスパゲッティを使用するそうだが、ないので De Cecco の No.12 を使用。

パスタデココでは小さなソーセージを使用していたが、記憶にある馴染みの店*1では極太のジャンボフランクが2本にソースだけというスタイルだったのを思い出し、両方を再現すべく、ジャンボフランク + 炒め野菜にした。

ジャンボフランクを焼きながら、玉ねぎと、ピーマン、赤ピーマン、マッシュルーム、ベーコンを炒め（胡椒で味付け）、これをボールに移して、残った油にオリーブオイルを足して、茹で上がったスパゲッティをさっと炒める。スパゲッティの上に具を盛り付け、暖めておいたソースを周囲に垂らして完成。

うまい。炒めたスパゲッティもうまいかも。でもソースがちょっといまいちかなあ。やはりレトルトでは再現しきれていないのだろうか。

「ヨコイのソース」が有名でしばしば耳にはしていたけど、店には行ったことがない。調べてみると、他に、コーミソースのコーミが出しているソースがあるようだ。「あんかけスパ レトルト」で検索してみると他にもいろいろあるようだ。

それにしても、末広町店は閉店するし、パスタデココは愛知県以外にはほとんど進出していない。レトルトソースも他地域では売られていないようだし、どうして他の地域に広がらないのだろう？ 名古屋にいたときは興味を持たなかったが、今となっては通販ででも入手したいところ。実家の地域でも売ってるだろうか。

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

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

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

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 の「証明書マネージャ」

結論

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

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