<前の日記(2008年12月13日) 次の日記(2008年12月27日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 106   昨日: 1370

2008年12月21日

SSLを要するモバイル環境でのパスワードマネージャの使い方に注意

Basic認証の話

この日記にSSLを導入した*1。基本的には自分用(編集時の安全を確保する)のもので、FirefoxとSafari(Mac OS版のSafari)からしか使えない*2*3。これにより、外出先の公衆無線LANからでも日記を編集できるようになった。

これまでは、自宅のコンピュータでしかログインしないようにして、http:// のままBasic認証を使っていた。パスワードが生のまま送信されるが、自宅の通信環境はまあ信頼できるので、(その先の通信路上で盗聴されるリスクがあるにしても)リスクは受容できると考えてきた。しかし、外出先で公衆無線LANを使うとなると、そのリスクは受容できない。6日の日記「公衆無線LANで使うと危ないiPod touchアプリに注意」にも書いたように、公衆無線LAN内の通信は簡単に傍受されてしまうし、偽アクセスポイントにつながってしまっても気付けない危険があり、https:// でのアクセスを必要としていた。

今回SSLを導入したので、このまま自宅のコンピュータを外に持ち出して公衆無線LANにつないでよいかというと、そうではない。なぜなら、たとえば、自宅でログインした後に、ブラウザを終了しないで、公衆無線LANにつないだとすると、ブラウザが覚えているBasic認証のパスワードが自動的に送信されてしまうからだ。

この危険は、「公衆無線LANに接続中は https:// でアクセスする」という使い方では防げない。なぜなら、たとえ目的サイト(たとえば自分の日記サイト)について https:// でアクセスするように心がけていても、その他のサイトではどうしてもどこかで http:// でアクセスせざるを得ない。その際に、通信路上でHTTPレスポンスを改竄されると、目的サイトの http:// 画面にリダイレクトさせられてしまう可能性があるからだ。そのときリダイレクトでジャンプした瞬間にパスワードが生で送出され、盗聴されてしまう。

したがって、公衆無線LANに接続することがあるかもしれないコンピュータでは、日頃から常に (Basic認証の)ログインは https:// で行うようにしておくのが正しい*4

といっても、一般の利用者にとってこの話は難しすぎるので、一般向利用者けにBasic認証を提供するのはやめた方がよいだろう。

パスワードマネージャの話

これに類する話として、ブラウザのパスワードマネージャの使い方にも注意が必要である。

たとえば、mixiのログイン画面(図1)はどう使うのが正しいだろうか。

画面キャプチャ

画面キャプチャ

図1: mixiのログイン画面

図1(上)のログインボタンの下に「SSL(https)はこちら」というリンクがある。これをクリックするとアドレスバーが同図(下)のようになる。これはどう活用するのが正しいか。

「自宅パソコンから使うときは最初の画面のままログインしてもよいが、公衆無線LANで使うときは必ず『SSL(https)はこちら』をクリックして、https:// の画面(図1下)になったのを目視確認してからパスワードを入力するようにする。」

この理解は正しい。Webサイト運営者側はそのつもりでこのようにしている。

しかし、問題はWebブラウザに搭載されているパスワードマネージャ機能の使い方である。

自宅の安全な通信環境で、http:// の画面でログインしたとしよう。初めてログインしたときは、ブラウザの上部が図2のようになり、入力したパスワードをパスワードマネージャに記憶させるか否かを尋ねられる。

画面キャプチャ
図2: パスワードマネージャの「このパスワードを記憶させますか?」

ここで「記憶する」ボタンを押して、パスワードをブラウザに覚えさせた場合どうなるか。これを押すと、次回以降、ログイン画面で図3のように、自動的にユーザ名とパスワードが入力欄に挿入されるようになる。

画面キャプチャ
図3: パスワードマネージャによりパスワードが自動的に挿入された様子

これは、このページにアクセスしただけでこのように自動挿入されるようになっている(Firefox、Safari、Google Chrome等の場合)。

ということは、この操作をしたコンピュータは、公衆無線LANなどでの接続を許すと、パスワードを盗まれるということだ。

画面上では「・・・・・・・」と表示されているが、これは見た目がそうなっているだけで、入力欄にはちゃんとパスワードの文字列が挿入されていて、ページ内のJavaScriptから参照すればパスワード文字列を読み出せる状況になっている。通常ならば、サイト運営者以外にはそのような読み出しはできないわけだが、公衆無線LANで接続している場合は違う。通信路上に介入した盗聴者によって、画面のHTMLを改竄されれば、パスワードを読み出すJavaScriptを埋め込まれてしまう。

というわけで、どうすればよいかというと、次のようになる。

  • 自宅にいるときに信頼できる通信環境だからという理由で http:// の画面でパスワードを入力することはあるにしても、そのコンピュータを公衆無線LANなど信頼できない通信環境に繋ぐ可能性もある場合は、普段から、http:// の画面で入力したパスワードをパスワードマネージャには記憶させないよう注意する必要がある。
  • https:// の画面で入力したパスワードについては、パスワードマネージャに記憶させてもよい。

http:// でログインしたときのパスワードマネージャの「このパスワードを記憶させますか?」の問いに対し、「このサイトでは記憶しない」を選択してしまえば、次回以降、この問いが出ることはなくなる。その場合でも、パスワードマネージャは http:// と https:// を別のサイトとして扱っているので、https:// の画面で入力したパスワードをパスワードマネージャに記憶させることはできる。

パスワードマネージャを使うことが許容される状況(そのコンピュータが自分専用)で、パスワードマネージャを使うつもりであるなら、いっそ、mixiのような構成のログイン画面では、自宅にいるときも含めて常に「SSL(https)はこちら」をクリックしてログインするようにするのがよいだろう。一度パスワードを記憶させれば2クリックでログインできる。

以上の話は、Firefox 3.0.5、Safari 3.2.1、Google Chrome 1.0での話である。

Internet Explorerの場合は、上記のような注意が必要でない。なぜなら、IEでは、パスワードマネージャにパスワードを記憶させても、ページを訪れただけでは自動入力されないからだ。ユーザ名を手作業で入力したときだけ、パスワードが自動入力されるようになっている。図4のように、ユーザ名入力欄でクリックすると、覚えているユーザ名をメニューから選べるようになっており、ユーザ名を選択すると対応するパスワードが自動入力される。

画面キャプチャ
図4: IEのパスワードマネージャではユーザ名の入力を必要とする

したがってIEの場合では、http:// でパスワードをパスワードマネージャに記憶させても、公衆無線LANでつながっても、ユーザ名を入力しないようにしていれば、パスワードを盗まれることがない。https:// のページに移動してから入力すればよい。

こうした、ブラウザごとの挙動の違いは、最近Googleが公表した「Browser Security Handbook」という文書にもまとめられている。part 3の「Password managers」のところに表がある。「Password manager operation model」のところで、IEについては「needs user name」、Firefox等については「auto-fills on load」と書かれている。Operaは「needs UI action」となっていて、また別の方式のようだ。

ちなみに、Googleの「Android」については、「Are stored https passwords restricted to SSL only?」が赤字で「NO」と書かれている。これはどういう意味かというと、https:// の画面で記憶させたパスワードが、http:// のページにアクセスしたときにも自動入力されてしまうという意味だろう。

これは危ない。現状のAndroidでは(おそらく近々修正されるのだろうが)、パスワードマネージャは使用してはいけない(信頼できない通信環境も使う可能性がある場合には)。

日本航空のEV SSL導入のナンセンス

先週、日本航空がEV SSLを導入したという話がニュースになっていた。

しかし、いったいどこのページに行けば、緑のアドレスバーで会社名を見ることができるのだろうか。

日本航空のログイン画面はトップページにあり、図5のように http:// のページになっている。

画面キャプチャ
図5: 日本航空のログイン画面

これでは EV SSLが台無しだ。緑であることも会社名も確認できない。mixiのように https:// に切り替えるリンクも用意されていない。ここの利用者達はどういう想いでパスワードを打ち込んでいるのだろう?

このサイトには他にもログイン画面があって、航空券の予約で便を指定した直後で図6の画面が現れる。マイレージ会員はここでログインするようになっているのだが、ここの画面も http:// であり、EV SSLの緑と会社名も確認できない。

画面キャプチャ
図6: 日本航空の別のログイン画面

ここで、自力でアドレスバーの http:// を https:// に書き換えてアクセスし、SSL接続を確認してからログインしようとしても、図7のようにエラーになってしまってできない。

画面キャプチャ
図7: 自力で http:// を https:// に書き換えてアクセスしてみた様子

いったい何のために日本航空は EV SSLを導入したのだろうか? わけもわからず買っただけなのではないか? 同社の「SSLについて」のページにいろいろ書かれているが、何もわかっちゃいない。

これをニュースにしたRBB TODAYの記事もどうかと思う。

今回、JALマイレージバンク(JMB)会員のログイン時に「お得意様番号」および「パスワード」を入力するサイト、一般乗客が航空券の予約時に顧客情報(氏名・年齢・性別・連絡先、クレジットカード番号など)を入力するサイトに導入された。JALはこれまでも、ログイン時やチケット予約時に日本ベリサインのSSLサーバ証明書を利用していたが、今回のリニューアルに合わせ、より強固なEV SSL証明書を導入したもので、サイトのトップページにもEV SSL証明書が導入されたとのこと(httpsでアクセスした場合)

JAL、国内航空業界で初めてフィッシング対策にEV SSL証明書を導入, RBB TODAY, 2008年12月15日

「(httpsでアクセスした場合)」と注釈を付けたくらいなのだから、この記者は、サイトの造りが駄目なのはわかっていたはずだ。わかっているならこんな記事を書いてはいけない。

関連:

*1 高負荷対策でレンタルサーバの契約コースを変更したため、SSLの導入が可能になった。IP-basedバーチャルホストで稼働しているため、専用サーバでなくてもSSLが利用できる。利用可能な暗号アルゴリズムの選択肢は、レンタルサーバ側で決められており、こちらで設定することはできないようだ。Firefoxのデフォルト設定ではAES 256ビットで接続されるようだ。

*2 IEやOperaではサーバ証明書が検証できない。認証局としてStartComのものを使用しているため。使用しているサーバ証明書は「Class 1」のものであり、本人確認はドメイン名に対する管理者権限をメールの到達性で確認するだけという、いわゆる「DV (Domain Validation) 証明書」である。StartComは、「WebTrust for CA」の認証局監査基準をクリアした正統な認証局であるが、Class 1のサーバ証明書については発行手数料を無料としている。DV証明書は他の認証局でも格安(数千円)で提供されており、そちらならIEやOperaでも使えるが、それらは証明書の署名アルゴリズムがいまだにMD5だったり、認証局のRSA鍵の長さがいまだに1024ビットだったりしたので、避けた。StartComの認証局はSHA-1と2048ビットである。DV証明書だからといって、認証局の安全な運営には多大なコストがかかるはずなのだから、無料というのが怪訝に思われるかもしれないが、StartComは、他にもClass 2、Class 3、そしてEV SSLのサーバ証明書を発行しており、そちらの利益で賄っていて、Class 1は宣伝になればよいという位置付けなのだろう。

*3 基本的には自分用(管理者用)であるが、閲覧者にとっても、内容が通信路上で改竄されていないことを確認するために活用できる。その際には、アドレスバーの「http」を「https」に変更してアクセスする。ただし、FirefoxまたはMac版Safariを使用して閲覧すること。

*4 公衆無線LANにつながりそうになる前にブラウザを必ず終了するという手順もあるが、おすすめできない。忘れそうだからという理由もあるが、いつ偽アクセスポイントにつながるかわからないので、そうならないよう、公衆無線LANの使用後に毎回それへの自動接続設定を削除するようにする必要もあり、これを徹底するのは無理があるから、おすすめできない。

本日のTrackBacks(全3件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20081221]

昨日Black Hatで「New Tricks For Defeating SSL in Practice」という発表がありました。海外のメディアでは既に早とちりして、適切でないタイトルで記事にしてしまっているところも見受けられます。 Website danger as hacker breaks SSL encryption タイトルだけ読むと、..

公衆無線 LAN を使うと、身元を隠せる。これを利用して、こっそりカンニングすることができるはずだ。やがて来るカンニングの完全犯罪を予告する。(?)

検索

<前の日記(2008年12月13日) 次の日記(2008年12月27日)> 最新 編集

最近のタイトル

2024年12月07日

2024年12月02日

2024年11月24日

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|12|
<前の日記(2008年12月13日) 次の日記(2008年12月27日)> 最新 編集