高木とは？

「オレオレ証明書」の問題が広く認知されるようになってきたのはよいが、オレオレ警告が出たとき、「お、オレオレじゃん。どうなってんの？このサイト」と、野次馬的に興味本位で「はい」を押して先を見に行ってしまう人も出てきているのではないかと心配になった。
大学や自治体サイトに「問題ありませんので」と書かれているのを見たことがあるので、「はい」を押して先に進むのが普通と思っている人
「オレオレ証明書」という話を聞いたことがあるので、これが出るサイトは駄目サイトだと思っていて、どうなっているか見に行ってしまう人
「オレオレ証明書」のことは理解しているつもりで、警告を無視したアクセス先で重要な情報（パスワード等）の入力さえしなければ問題ないと思っていて、どうなっているか見に行ってしまう人
正しく理解していて、オレオレ警告が出たときは基本的に「いいえ」を押すようにしているが、正しい手順を経てその先を見に行くこともある人
「オレオレ警告が出たらそこは駄目サイト」という理解は誤りだ。閲覧している人がそのタイミングで（通信路上で）攻撃を受けているだけで、サイト自体は正常である場合もある。オレオレ証明書が問題なのは、サイト自体が異常な設定をしていると、サイトが異常なのか、閲覧者が攻撃を受けているのか、区別つかないという点にある。上記のうち正しい行動は、1.と 5.と 6.だけである。
これまで、オレオレ警告時は「いいえ」を押してアクセスしないのが当然であるとし、もし「はい」を押して先に進んだ場合にどんな危険があるのかについては、あまり具体的に整理してこなかった。上記4.のパターンの「重要な情報（パスワード等）の入力さえしなければ問題ないと思っていて、どうなっているか見に行ってしまう」という行動が、どのように危険なのかを以下に整理してみる。
たとえば、銀行やネットショップでログイン中のとき（パスワードを送信するときは警告は出なかったとして）、あるタイミングでオレオレ警告が出たとしよう。「あ、オレオレ証明書じゃん。どうなってんの？このサイト」と、とりあえず警告を無視して先に進んだとしよう。その瞬間何が起きるだろうか。
つまり、図1の画面で「はい」ボタンを押した瞬間、また、図2の画面で「推奨されません」のリンクをクリックした瞬間、図3の画面で「OK」ボタンを押した瞬間、図4の画面で「承認する」ボタンを押した瞬間、図5の画面で「Continue」を押した瞬間、図6の画面で「続ける」を押した瞬間、図7の画面で「はい」を押した瞬間、何が起きるだろうか。
もし通信路上に盗聴者がいた場合*2、そのcookieは盗聴される。セッションIDが格納されているcookieが盗聴されれば、攻撃者によってそのセッションがハイジャックされてしまう。
「重要な情報さえ入れなければいいのだから」という認識で、オレオレ警告を無視して先を見に行ってしまうと、ログイン中のセッションをハイジャックされることになる。
さすがに、銀行を利用している最中でオレオレ警告が出たときに、興味本位で先に進む人はいないかもしれないが、銀行を利用した後、ログアウトしないで、別のサイトへ行ってしまった場合はどうだろうか。通常、銀行は数十分程度で強制ログアウトさせる作りになっているはずだが、その数十分の間に、通信路上の盗聴者により、銀行サイトへリダイレクトさせられた場合どうだろうか。
閲覧者としては、ニュースなどを読んでいる最中に突然オレオレ警告が出るという体験をする。ここで、ニュースサイトが出している警告だと思い込んで、そのまま「はい」で先に進むと、さっきまで利用していた銀行にアクセスしてしまい、送信するcookieを盗聴されてしまう。
このことは、17日の日記「こんな銀行は嫌だ」の件に関係する。電話で問題点を指摘した際、こんなやりとりがあった。
私: どういう責任を感じてるんですかね。これ間違ったことを、嘘を教えているわけでしょ？ おたくのユーザに、赤くなってても使って大丈夫だと教えてるわけでしょ？ 推奨されませんとまで書いてあるのに、それを押せと、言ってる。「セキュリティ上の問題はございません」て書いてあるでしょ？ そういうものだって理解しますよね？ これ読んだ人は。赤くなっていても問題ないのだと、教えられるわけですよね？ そういう誤った知識を植えつけてしまったことに対する責任をどう考えてるんですか？ おたくは。
私: どういうふうに検討されるんですか？ 間違ったことを書いてましたと、赤くなってるときは使ってはいけないのに、
銀: あのー……。そうか……。……。これは、すべての場合のInternet Explorerをご利用の場合にというアナウンスではないんですけどもね。
銀: Internet Explorer 7で推奨されませんと出たときの、すべての場合でそのまま押してくださいと申してるものではないんですども。
つまり、銀行側の言い分として、この警告を無視してよいと言っているのは「ビジネス情報サイト」についてだけであって、他のサイトについては言っていないというわけだ。しかし、次の被害シナリオが考えられる。
この銀行のインターネットバンキングを利用した人が、インターネットバンキングをログアウトしないで、「ビジネス情報サイト」を閲覧しに行ったとする。このとき、通信路上の盗聴者が、閲覧者のブラウザをインターネットバンキングのサイトへとリダイレクトさせ、通信路上でサーバ証明書を攻撃者所有の証明書に置き換えたとする。そうすると閲覧者のブラウザにはオレオレ警告が出るわけだが、閲覧者は、いつもの「ビジネス情報サイト」にアクセスしようとしていると思っているので、そのオレオレ警告を無視して「はい」を押してしまう。この瞬間、インターネットバンキングサイトに（盗聴されながら）アクセスすることとなり、cookieを盗聴され、セッションハイジャックされてしまう。
もっと酷いことに、これはその銀行だけで被害が済む話ではない。閲覧者が、他の銀行であるメガバンク等にも口座を持っていて、メガバンクのインターネットバンキングにログインしている最中に、この地銀の「ビジネス情報サイト」を閲覧しに行ったら、真面目にサイトを作っているメガバンクの方で被害が出てしまう。
cookie窃用によるセッションハイジャックだけならば、たいして重大でない場合もある。セキュリティを重視したサイトでは、たとえセッションハイジャックされても重大な被害が出ない構成にしていることがある。たとえば、個人情報を閲覧する画面に入る際には再びパスワードの入力を必要とするとか、振込み操作を実行するにはワンタイムパスワードの入力を必要とするといった構成だ。*3
しかし、cookie窃用によるセッションハイジャックとは異なり、今想定しているケースでは、通信路上に盗聴者が入っている（SSLを使っているのにオレオレ警告を無視した）のであるから、常時、通信内容を盗聴されたり改竄されている可能性がある。
したがって、本人が、個人情報閲覧画面に入ろうとしてパスワードを送信したとき（そのパスワードも盗まれるが）閲覧する個人情報は盗聴されるし、また、たとえワンタイムパスワードを使っていても、9月23日の日記で書いたman-in-the-middle攻撃の場合と同じ危険がある。（IE 7 ではアドレスバーが赤くなっているので異常な状況を判別できるが、それ以外のブラウザでは、オレオレ警告を無視した後の状態であることを判別できない。）
銀行では比較的短時間で強制ログアウトさせられるが、長時間ログインしっぱなしで使う、ブログやSNSサイト等では、これが現実となる可能性がより高くなるだろう。
また、ログイン中でなければ大丈夫というものでもない。オレオレ警告は1度しか出ない点に注意が必要である。
あるタイミングでオレオレ警告が出たとする――(a)。「ログイン中でないから大丈夫だろう」「何も入力しなければ大丈夫だろう」と興味本位で先に進めてみたとする。そのときは何も起きなかったとする。それから何日かして、そのことをすっかり忘れているときに、インターネットバンキングを利用するとき、実はそれは盗聴されているということが起こり得る。
つまり、(a)のオレオレ警告は通信路上の盗聴者がしかけたオレオレ証明書によるものであり、それを一旦受け入れてしまった閲覧者は、その後、同じ盗聴者がいる通信路上でアクセスすると、警告なしに盗聴されてしまう。ログインしようとパスワードを送信する時点から盗聴される。（IE 7 ではアドレスバーが赤くなっているので異常な状況を判別できるが、それ以外のブラウザでは、オレオレ警告を無視した後の状態であることを判別できない。）
これを回避するには、ブラウザを再起動する必要がある。昨今のWindowsは安定して動くので、何週間にもわたって起動しっぱなしで使うのが普通になっている。iPod touch の場合は Safariを再起動する手段さえ用意されていない（11月23日の日記参照）。
オレオレ警告をあえて無視して先を見に行こうとするとき、証明書の内容を確認すれば大丈夫と言えるだろうか？
たしかに、警告の内容と証明書の内容によっては見に行って大丈夫な場合もある。しかし、大丈夫かどうかは、素人には判別が難しい。
たとえば、11月17日の日記の地銀ネットワークサービスのビジネス情報サイトの場合、発行先が「www.cns-jp.com」となっていて、アクセス先のサーバと食い違っているために警告が出ている。したがって、証明書の内容を表示させて確認し、発行先が「www.cns-jp.com」であることを目視確認すれば、見に行っても大丈夫だと言うことも可能だ（ブラウザによっては）。
しかしそのとき、証明書の発行者が正規の認証局であることも同時に確認しなければならない。つまり、Intnernet Explorer ならば、図8の (a) と (b) のどちらなのかを見分けなくてはならない。
PSPの場合、図7の1つ目と2つ目の警告を見分ける必要があるが、それらの意味の違いをいったいどれだけの人が理解できるというのだろう？
また、Internet Explorer 7 では、アクセスする前に証明書の内容を確認することができなくなった。図2のように、証明書を確認するためのボタンやリンクは存在しない。確認するには、一旦「このサイトの閲覧を続行する（推奨されません）」をクリックして先へ進み、図9の「証明書のエラー」となっている部分をクリックして初めて証明書の内容を閲覧できる構造になっている。その画面を見た時点で既に盗聴者にcookieが送信されているので、後の祭りだ。
iPod touchにいたっては、証明書の内容を確認する機能がそもそも存在しない（上記の図6および、10月20日の日記参照）。
加えて、Firefox 2 と Safari 2 には別の危険性があることが、先週 Bugtraqに投稿された記事で指摘された。
オレオレ警告を無視してしまうと、その後、同じオレオレ警告は出なくなるわけだが、「同じ」というのはどこで判別されるのか。
Firefox 2 では、証明書単位で覚えておく実装になっているようだ。そのため、次の挙動が起こり得る。
サイト A へ接続する際に、不明な認証局から発行されたオレオレ証明書（ホスト名は A として発行されている）が提示された場合、
ブラウザは、「未知の認証局により認証されています」の警告は省略するけれども、ホスト名が B であるはずのところ A になっているという警告（図10）を出す。
つまり、サイト A でオレオレ証明書を受け入れた閲覧者は、証明書の内容を目視確認して、サイト A 用の証明書だと承知の上で受け入れたのであろうから、サイト A で盗聴の危険に晒されるのは閲覧者の自己責任である ―― という立場をとることが可能だ。
もし、サイト A への接続時に、図3の警告だけでなく図10の警告も現れて、そのオレオレ証明書がサイト B 用のものであると示されていた場合は、閲覧者は、B が重要なサイトでないかを確認しなければならない。もし、B が重要なサイトなのにそのオレオレ証明書を受け入れてしまうと、後に B のサイトへ行った際に、警告は出ず、盗聴されてしまうことになる。
したがって、Firefox 2 では、オレオレ警告時に見るべきは証明書の発行先のホスト名であると言える。
具体的に言うと、たとえば「ビジネス情報サイト」を訪れたときに、通信路上の盗聴者により、攻撃者自作のオレオレ証明書が提示されたとする。まず図3の警告が出るが、「『ビジネス情報サイト』だからどうでもよい」という判断でこれを受け入れたとする。さらに図10の警告も出たときに、内容をよく見ないで受け入れたとする。そのとき、実は図10の警告に、
と書かれていたとすると、それは危険な状態となる。インターネットバンキングの本物サイトである、「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 と Internet Explorer を比較すると、オレオレ警告に対してユーザがどう対処するべきかの考え方に違いがあるように思える。
Firefox は、ユーザの自己責任の下、証明書の内容を確認して受け入れる仕組みを用意する方向性で設計されている。対して、Internet Explorerは、IE 7 での改良で、警告時に証明書の内容を表示する機能を省いてしまい、そもそも確認できないように設計変更された。これは、「ユーザに確認することは無理だから、警告発生時にはアクセスを継続するな」（「推奨されません」）という方針で設計されていると言えるだろう。
Firefox はプロ向け、マニア向けと言えるかもしれないが、受け入れても大丈夫な証明書であることをきちんと確認できるだろうか。
IE 7 と同様に、ダイアログウィンドウでの警告はやめて、画面全体でエラーが表示されるように改善された。（どのサイトにアクセスしようとして出たエラーなのか、アドレスバーで確認できるようになっている。）
それでもアクセスを継続する手段は残されているのだが、IE 7 と異なるのは、IE 7 では「証明書のエラー」のまま、アドレスバーの赤い表示でアクセスを継続させるのに対して、Firefox 3 では、証明書の内容を確認して、証明書を登録してからアクセスするようになっている。図11の「例外として扱うこともできます」の部分をクリックすると、図12のようになる。
「例外を追加」ボタンを押すと図13のウィンドウが現れる。ここで何を確認すれば安全と言えるのか、一般の人たちにそれが理解可能だろうか？*4
たとえ、それぞれのブラウザで安全にオレオレ警告を扱う方法が用意されているとしても、それは、たまたまそのブラウザがそのような実装になっているというだけで、SSLの仕様に基づいた挙動ではないという点に注意したい。サーバ証明書の正当性検証ができない状況は、致命的エラーなのであって、そのときに例外的に扱う方法は定義されていない。
図13: Firefox 3 曰く「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません」
「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません」とあるように、本物の銀行や公共サイトがこのような操作を強いることがあってはならない。
また、Firefox 3 の「セキュリティ例外を承認」の機能は、興味本位で見に行くためのものではない。Firefox 2 までの「このセッションの間だけ一時的に証明書を受け入れる」（図3）の機能は廃止された。「セキュリティ例外の承認」は、「今後この証明書を受け入れる」を選択した場合に相当する。「証明書マネージャ」（図14）で受け入れ済み「サーバ証明書」のリストから削除するまで、この状態は続いてしまうので注意が必要だ。
話が長くなったが結論は単純で、「オレオレ警告が出たらいかなる場合もアクセスを中止すること」と心得ておけばよい。
興味本位でオレオレ警告の出るサイトを見に行く場合には、十分な知識を持って適切な手順でブラウザを使用しないと、被害に遭う危険性がある。
*2 このような事態はごくごく現実的に起こり得る。最も現実的な例としては、たとえばlivedoor Wirelessのような方式の公衆無線LANでは、偽のアクセスポイントを設置することができてしまうので、偽の方につながってしまうと、攻撃者は簡単に盗聴や改竄、偽DHCPサーバおよび偽DNSサーバの設置等ができてしまう。そんなリスクがあっても安全に使えるようにするのが SSLであり、銀行等が顧客に対して「SSLを使用しています」と胸を張って約束するのはそのためであろう。
*3 クロスサイトスクリプティング脆弱性に備えてこのような作りにしているサイトはけっこうある。また、ブログやSNSサイトのように、SSLを一部のページにしか使っていないサイトの場合、セッションハイジャックは重大な脅威でないという方針をとっている場合がある。つまり、パスワードを保護するためだけにSSLを使い、http:// のページでセッションハイジャックされても、重大なページへ入るには再びパスワードの入力を要求する作りにしていることがある。
*4 ここで、「セキュリティ例外を承認」を押した場合、「サーバ」欄に書かれているURLに対してだけ、この例外が適用されるようなので、このURLのサイトの重大性だけ判断すればよいように思えるが、これで正しいだろうか……。
名古屋を離れてすっかり忘却していたあの喫茶店のスパゲッティの味。実は「あんかけスパ」と呼ばれる名古屋固有の特殊な料理だと理解したのは数年前。ココイチが「パスタデココ」なる店を始め、虎ノ門に店があると知り、霞ヶ関に用事があった帰りに何回か行っていた。その後、秋葉原へ転勤になると、近くに末広町店があるというので、ランチに嫌がる職場の同僚を引き連れて食べに行っていた。その店が1年前に閉店。閉店を惜しんで買った店頭売りのレトルトソースが、賞味期限切れになっていた。
というわけで食べてみた。本場は 2.2 mm のスパゲッティを使用するそうだが、ないので De Cecco の No.12 を使用。
パスタデココでは小さなソーセージを使用していたが、記憶にある馴染みの店*1では極太のジャンボフランクが2本にソースだけというスタイルだったのを思い出し、両方を再現すべく、ジャンボフランク + 炒め野菜にした。
ジャンボフランクを焼きながら、玉ねぎと、ピーマン、赤ピーマン、マッシュルーム、ベーコンを炒め（胡椒で味付け）、これをボールに移して、残った油にオリーブオイルを足して、茹で上がったスパゲッティをさっと炒める。スパゲッティの上に具を盛り付け、暖めておいたソースを周囲に垂らして完成。
うまい。炒めたスパゲッティもうまいかも。でもソースがちょっといまいちかなあ。やはりレトルトでは再現しきれていないのだろうか。
「ヨコイのソース」が有名でしばしば耳にはしていたけど、店には行ったことがない。調べてみると、他に、コーミソースのコーミが出しているソースがあるようだ。「あんかけスパ レトルト」で検索してみると他にもいろいろあるようだ。
それにしても、末広町店は閉店するし、パスタデココは愛知県以外にはほとんど進出していない。レトルトソースも他地域では売られていないようだし、どうして他の地域に広がらないのだろう？ 名古屋にいたときは興味を持たなかったが、今となっては通販ででも入手したいところ。実家の地域でも売ってるだろうか。
*1 大学の近くにあった何の変哲もない喫茶店。学部生時代、土曜に学友のアパートに転がり込み、泊まって起きた日曜の昼、食べるところがそこしかなく、いつも食べるのがそのウインナースパだった。たしかこの場所。
このブログも始めて4年半になるが、一昨日、初めていわゆる「削除依頼」を受け取った。というわけで、17日の日記に追記した。
それはともかく、その追記を書いている際に、iPod touch の Safariにセキュリティに関わるバグを発見した。これは、脆弱性と言うこともできるバグではあるが、この事実を公表することにより増大し得る危険性の差分が十分に小さいのに対して、この事実の公表で利用者が自衛できるようになることによる安全性の向上の方が十分に大きいと判断し、以下にこの事実を記す。
iPod touchで https:// のサイトに接続した際、SSLのサーバ証明書の異常を示す警告（通信路上で盗聴等が行われようとしている可能性を示す）が出たとする。ここで「キャンセル」「続ける」のどちらのボタンもタッチせずに、本体下部にある「□」印の物理ボタンを押すと、どうなるか。
「□」ボタンを押すとメニュー画面に戻るので、ここで「Safari」アイコンをタッチすると、直前に表示していたWebサイトが現れるが、ここで、さきほどのリンクをタッチして再び同じ https:// サイトにアクセスしようとしてしまったとする。
すると、本来ならば再び「オレオレ警告」が出なくてはならないのに、警告が出ずに、ページにアクセスしてしまう。（ただし日本語テキストの文字化けすることがあるようだ。）
したがって、オレオレ警告が出ている最中に「□」ボタンを押してはいけない。もし押してしまったら、その後は同じ https:// サイトへ行かないように注意しなくてはならない。
これは、https:// サイトをブックマークしている場合にも同様に注意が必要だ。ブックマークからいつものログインサイトを選択したときに、もし「オレオレ警告」が出たら「キャンセル」を押さないといけないが、慌てて「□」ボタンを押してしまうと、その後再びブックマークから同じログインサイトへ行ったとき、警告が出ず、盗聴されているのに気づかずにパスワードを送信してしまうという事態が起こり得る*1。
ブラウザを再起動すれば元の状態に戻るが、iPod touchの Safariには終了の機能がないようなので、Safariがクラッシュして落ちるのを待つか、iPod touch自体の電源を完全に切る必要がある。本体上部左にある物理ボタンを長押し（数秒間）して、「電源オフ」の赤スライダを出して、それをスライドさせて切る。（電源を入れるには再び長押しする。）
脆弱性として扱われるかはわからないが、念のため、IPAの脆弱性届出窓口に届け出て製品開発者に修正を促してみる。
*1 文字化けが起きない場合。また、テキストの文字化けが起きていても（画像ばかりの画面などの原因で）気づかない場合。
5日の日記「ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する」の続き。
Windows XPでは、デフォルト設定では、「自動」接続設定されたアクセスポイントの各SSIDを常時ブロードキャスト、つまり周囲に撒き散らしているので、SSIDのプライバシー性が特に重大だった。では、他の無線LAN対応機器はどうか。いくつか調べてみた。
以下の「自宅を特定されない使い方」で、自宅のSSIDの変更が必要かについては、5日の日記と、6日の日記「位置特定につながるSSIDの割合は約17%」を参照。（もちろん、世の中にPlaceEngine（と同様のサービス）が存在しなければ、そんなことにはならないのだが……。）
スリープから復帰した直後に（パスワード認証をする前の時点から）、直前に接続していたアクセスポイントのSSIDをprobe requestとして、約10秒間ブロードキャストする。
それに接続できない場合、その前に接続していたSSIDについて同様にブロードキャストする。それに接続できない場合はさらに前に接続していたSSIDについて同様に、と、すべての覚えているSSIDについて続く。
覚えているSSIDを削除する方法がよくわからない。キーチェインから削除すると消えるっぽい。接続中のSSIDは削除できないっぽい。
接続できるアクセスポイントのない場所で電源を入れていると、その間、周囲で自宅SSIDを傍受され得る。
接続できるアクセスポイントのある場所（勤務先等）では、自宅から持ってきて最初にスリープから復帰させた際の約10秒間、周囲で自宅SSIDを傍受され得る。
自宅を出たら、自宅アクセスポイントから十分離れて接続しなくなった時点で、スリープから復帰させ、キーチェインから当該SSIDを削除してから、目的の場所に向かう。
電源を入れたとき、直前に接続していたアクセスポイントのSSIDをprobe requestとして、約1秒間ブロードキャストする。
「設定」の「接続」の「ネットワークカード」で、「ワイヤレスネットワークの構成」から、当該SSIDの項目を選択して「メニュー」から「設定の削除」を選ぶ。
接続できるアクセスポイントのない場所で電源を入れていると、その間、周囲で自宅SSIDを傍受され得る。
接続できるアクセスポイントのある場所では、自宅から持ってきて最初に電源を入れた瞬間に、周囲で自宅SSIDを傍受され得る。
電源を入れ無線LANをオンにしたとき「ワイヤレスLAN接続」で「登録済み」となっている接続先リストの上から順に接続が試みられる。
各接続先について、接続できない間、そのSSIDをprobe requestとして30秒間ほどブロードキャストする。
電源を入れ無線LANをオンにしたとき、「登録済み」接続先リストの上の方に自宅のSSIDが登録されていると、それへの接続が試行される前に中止しないでいると、その間に周囲で自宅SSIDを傍受され得る。
それはあまりに不便なので、自宅SSIDを「登録済み」接続先リストの下の方に設定しておき、上の方に勤務先やその他のアクセスポイントを登録しておき、電源を入れ無線LANをオンにしたときに、自宅への接続が試みられる前に中止する。
電源を入れて「インターネットブラウザ」を起動しどこかへ最初にアクセスするとき、前回接続していたアクセスポイントのSSIDをprobe requestで一瞬だけブロードキャストする。
「ネットワーク接続」画面で「利用する接続を選択してください」と出た場合は、ここで選択した接続先のSSIDを1秒間ほどprobe requestとしてブロードキャストする。
自動接続をやめる。「インターネットブラウザ」の「ツール」メニューの「設定」で、「接続設定」を選び、「利用する接続」を「自動選択」ではなく「手動選択」に変更する。
「インターネットブラウザ」の接続設定が自動選択になっている場合、電源を入れて「インターネットブラウザ」を起動しどこかへ最初にアクセスするとき、前回接続していたアクセスポイントが自宅だった場合、その瞬間に周囲で自宅SSIDを傍受され得る。
「インターネットブラウザ」の「接続設定」で「手動選択」に設定（上記の通り）しておき、アクセス時に出る接続先の選択画面「利用する接続を選択してください」で、自宅SSIDを選ばないように気をつける。
電源を入れたとき、前回接続していたアクセスポイントのSSIDをprobe requestとして、一瞬だけブロードキャストする。
それ以降は、そのSSIDでのprobe requestはブロードキャストされない。（電源を切って入れ直しても。）
自宅を出て、どこでも電源を入れず、どこかで最初に電源を入れたとき、その瞬間に周囲で自宅SSIDを傍受され得る。
無線LANの「SSID」は、どれが自分の使ってよいアクセスポイントなのかを人間が見分けるための名前でもあるのだから、本来、覚えやすい名前にしておくべきものではないだろうか。
これは、接続の設定をするときだけの話ではなく、今どこにつながっているかを確認する癖を付けるという意味でも重要ではないか。ゲーム機やiPod touchのように持ち運ぶ機器が無線LAN接続をするのが普通になってきたからだ。
昨今の無線LANアクセスポイント製品は、デフォルト設定が覚えられないような番号になっていたりするが、隣の家のSSIDを自分の家のものだと間違えてしまうことがありそうだ。もちろん、逆に、ご近所がみな同じ「YBBUser」というのも困る。
セキュリティの半可通が、「SSIDは予測困難なランダムな文字列にしておくのが常識」などと「キリッ」とした顔で言うかもしれないが、それは無視してよい。WPAによる暗号化さえ正しく設定（これは元々必須）しておけば、SSIDを知られたところでセキュリティ上の問題はない。そもそも、元々SSIDは電波に載って飛んでいるので隠すことは不可能だ（ステルス機能でも隠し切れない）。
SSIDの名前をランダムにしないことに問題があるとすれば、プライバシーの観点からだろう。家庭の無線LANのSSIDにふさわしい名前の要件を列挙すると、こんな感じだろうか。
例：動物の名前、食べ物の名前、星の名前、芸能人の愛称、子供向けアニメの名前、思い出の旅行先の名前など。
例：興味をそそるような名前を避け、平凡な名前に。子供がいることを知られたくなければ、子供が好きそうなものの名前を避ける。
自分の家のSSIDと同じ名前のアクセスポイントが、暗号化なしで利用可能になっていても、接続しないこと。

[ 45] 高木浩光＠自宅の日記
[引用サイト]　 http://takagi-hiromitsu.jp/diary/



高木とは？トップへ↑

お気に入り



  • track feed
    • seo