eggshell blue

au ケータイで公式IMAP その2

mobile |

d:id:RobinEgg:20120909:p1 で書いた EzWeb メール（@ezweb.ne.jp）への IMAP アクセスに関する話ですが、どうやら改悪後、さらに更新があったようで、最終的には端末との紐付けを行った au ID によるログインで、設定の変更が可能になったようです。

ただし、

• 設定画面への接続は au の回線（3G/LTE/WiMAX）を経由しなければならない
• User Agent が iPhone でなければならない

ことは変わりないようです。

2013年夏頃を目処に IMAP アクセスをオープンにするとの公式アナウンスもあることから*1、これらの制限については近日中に撤廃されるのではないでしょうか。なお、変更画面のアドレスは

https://set.mail.ezweb.ne.jp/md/signin

です。

公衆無線LANサービスの自動ログインスクリプト

dev |

Python 版 WISPr クライアントはじめました。

国内で展開している、主に携帯キャリアの公衆無線LANサービスに対応した自動ログインスクリプトを公開します。

これまで色々と各キャリアの無線LANサービスについて書き連ねてきたわけですが、ここらでひとつコードとして纏めておこうと思い、さくっと書いてみました。NTT系以外*1の公衆無線LANサービスで動作確認を行っています。

ソースはこちら:　 tamias / PyWISPr / source / — Bitbucket

作成の経緯

そもそもは3G回線契約を持たない Android 端末でどうにか簡単に使えないかなというのが発端であり、純正アプリは軒並み低評価ということもあって、まずは Android 版の作成を考えていました。

が、1から作るのはなぁ…と思っていたところ、オープンソース(GPL)で公開されている 1st-wispr client の存在を知り、初めのうちはこれをベースにある程度使い物になるところまで作りかけたのですが、公開することを考え始めると、このアプリ、作者が台湾の方のようで、ソースコード内に台湾で展開しているサービスに特化した部分が複数あり、それらを逐一書き換えていくのはあまりにも骨が折れる作業だったため、結局フルスクラッチで書き上げることにしました。

似たようなスクリプトは既に「au Wi-Fi SPOTにLinuxから接続できるようにしてみた - Dマイナー志向」で作成されていましたが、あちらはユーザー情報を逐次入力するという、キーボード端末前提で書かれていたこと、また特別なUser Agent指定が必須の一部サービスには対応していなかったこと、そして何より Perl で書かれていたため、新たに作成し直すことにしました。

新規に作成するにあたり、 WISPr プロトコルへの準拠度を高めようとしましたが、以前のエントリでも書いたとおり、現行バージョンの2.0ならともかく、1.0を使うサービスが大勢を占める現状では準拠という言葉を使えないものの、それなりに想定されうるロジックは網羅しているはずです。

言語については携帯端末でもノートPCでも動作可能なものをと思い、Air/JavaScript などのより移植性の高い言語も考えたのですが、最終的になんだかんだで使いやすく、また Android であれば SL4A を通せば携帯端末でも動作する Python に落ち着きました。こちらの対応版は併せて PyWispr_sl4a.py として公開しています。中身というか処理ロジックは全く同じですし、大本の PyWispr.py も Android/SL4A 上で普通に動きますが*2、動作通知やパスワードファイルの保存位置などが携帯端末環境に適したコードになっています。

各社、というか主にソフトバンクモバイルとワイヤ・アンド・ワイヤレスですが、User Agentを見て自社端末かどうかの識別を行っているようで、前者は特定の文字列がないと自社端末として見なさず、ログインさせないという方針をとっており、後者の一部のアクセスポイントでは逆に他社を特定可能な一部の文字列が存在すると、そもそもレスポンスを返さないという挙動を示すものがあります。これらの処理のせいで煩雑なコードになってしまっており、もうちょっとどうにかしてくれないかなぁというのが正直なところです。キャリアロックインを進めるのを止めるわけではありませんが…。

このような事情から、認証情報を記入する secret.xml に、ユーザーID、パスワードに加えて User Agent を記載しています。通常は User Agent 値を変更する必要はないものの、変更することは可能ですが、変更に伴って接続ができなくなる場合がありますのでご注意ください。

動作確認環境

標準ライブラリのみを使用して作成していますので、別途必要なライブラリはありません。

ただ、 XML のパースに ElementTree を使用していますので、これが標準で入っていないPython 2.5以前のバージョンでは別途導入およびコードの修正が必要です。その他、バージョン更新に伴って新たに導入されたメソッド群が存在している可能性がありますので、なるべく最新の環境で動作させることをお勧めします。 → Python Download

PyWispr

• Python 2.6.2 以上

PyWispr_sl4a

• Galaxy Nexus（Andrid 4.1.2）
• Python for Android (Interpreter: 16, Extras: 14, Script: 13) (apk)
• SL4A (Release 6 (apk))

つかいかた

1. アクセスポイントへのWEP/WPAキーを入手し、OSに登録する cf) network/公衆無線/ホットスポット一覧 - Tomocha WikiPlus
2. secret.xml を編集し、利用するサービスの認証情報を記入する*3
3. 実行スクリプト（PyWispr.py もしくは PyWispr_sl4a.py）と secret.xml を同階層に保存する
4. 外出し、認証情報を登録したサービスの無線LANアクセスポイントに接続する
5. スクリプトを実行する
6. 通常の環境の場合、ログインに成功すると Enter でログオフするか Ctrl+C で終了するか問われますので、状況に応じてご利用ください

注意点

• 自己責任でご使用ください。サービスによっては、明確に自社配布アプリ経由以外での接続を禁じている場合があるかもしれません。
• 本スクリプトでは、SSL証明書の確認は実施していません（Python 側の仕様です）。成りすましAPにはくれぐれもご注意ください。
• SL4A では /sdcard/sl4a/scripts が保存フォルダになります（環境依存の可能性アリ）。ただし、実行時のCWDは /sdcard/sl4a です。
• au_Wi-Fi の一部のアクセスポイントではログオフ機能は機能しません。これはログオフ機能のAPIがAP内のアドレスとなっているのに対し、認証に成功すると二度とAP内のアドレスを参照することができなくなるというサービス側の仕様によるものです。

スタバでのドヤリングのお供にも、コンビニ駐車場でのネットにも、どうぞご利用ください。

WISPr について

dev |

図らずも数ヶ月に渡って公衆無線LANサービスについて色々と書いてきましたが、その中で出ていたWISPrについての説明を少々しておこうと思います。

そもそもWISPrとは、 "Wireless Internet Service Provider Roaming"の頭文字を取ったものです。ここからわかるとおり、無線ISP間のシームレスなローミングを目的として策定が行われています。

Ver.1.0 は Wi-Fi Alliance 主導の下、2003年2月に策定が行われました。このバージョンでは、バックエンドにRADIUSを、フロントエンドにHTTPを用いた形が想定されており、Appendixという形で802.1xによる認証方式が記載されています。

が、策定時点において既に規格よりも実装が先行していたため、あくまでも「ベストプラクティス」集として制定されました。このため、特許など知的財産権侵害の可能性検討など、標準規格として必須の処理が行われないままに策定されてしまい、その辺りの処理は実装ベンダーに任されるような形になってしまいました。また、RFC2119で示されるような、いわゆる SHOULD/MUST/MAY を用いた実装要求水準が示されておらず、実装側もどの程度まで盛り込めば「準拠」と名乗れるのかがわからないという代物だったので、これらの問題点の解決を目標に、2010年4月、今度はWireless Broadband Allianceが主導してWISPr 2.0 が策定されました。

2.0では、1.0のAppendix Dで規定されていた"Smart Client to Access Gateway Protocol"を拡張するという形で規格が決められており、クライアント側の接続仕様（要はフロントエンド側）に焦点を絞ることで、よりクリアな規格とするような努力が払われています。また、このAppendix D以外に関する規定、例えば802.1xに関するものなどは全て棄却されており、代わりにEAP（Extensible Authentication Protocol）への統合が試みられています*1。

もちろん、旧来の規格を捨て去るわけにはいかないので、後方互換性を取るよう図られています。が、個人的には一般的な公衆無線LANサービスにはEAP方式の認証は重すぎることもあり、2.0系はあまり普及しないのではないかなと思っています。また、国内で既に展開済みの携帯キャリアによる公衆無線LANサービスでは、ドコモが接続開始時には2.0でアナウンスし、その後1.0への移行を宣言、KDDI系（au/wi2）、ソフトバンク系（0001softbank/mobilepoint）は接続開始時から終了時まで全て1.0となっています*2。

仕様書とXML Schemaはそれぞれ以下の場所で配布されています。

WISPR 1.0

• 仕様書: WISPr_V1.0.pdf
• XML Schema: http://www.acmewisp.com/WISPAccessGatewayParam.xsd

WISPR 2.0

Wireless Broadband Alliance の公式ページでメールアドレスを入力すると、ダウンロードサイトのアドレスが送られてきます。

au ケータイで公式IMAP

mobile |

更に追記

2013.04.01 現在、au ID によるログインで設定変更が可能になったようです。新たに記事を立てましたので、詳細は d:id:RobinEgg:20130406:p1 をご覧ください。

追記

2012.12.03現在、改悪されてしまったようです。

下記に記載している送信先番号の「00900000」は「00900015」に変更になり、この番号にSMSを打った時点で強制的に非公開モードに変更されてしまうようです。

下記でも記載していますが、非公開とはいえ、中身はIMAPなのですが、ID/Passを公開してくれないため手も足も出ないようです。

iPhone専用番号である「#5000」はまだ生きているのでこちらに送信してやれば何とか使えはするのですが、下記記載の通り、一部端末を除くと純正メッセージングアプリはおろか、Google Playで公開されているようなSMSアプリケーションを使用しても特殊番号への送信ができない、というのが現状であるため、今後は望み薄だと思われます*1。

しっかし、なんでこんな改悪しますかね。Mediba ad の IS NETシュリンクラップ契約も大概ですが、最近ほんと酷い > KDDI。

以下、公開当時の文章

いまだに au one メールとか言ってる情弱はお呼びじゃないですね。

au では、昨秋のiPhoneの導入に伴って公式にIMAPサーバーとSMTPサーバー（とExchange（ActiveSync/DirectPush）サーバー）を一般に公開しました。これはすなわち、

• どこの回線からでも、どんなIMAPクライアントからでも、ezweb Mailを確認することができる
• さらにキャリアSMTPサーバーを経由してメールを送信することができる

という、これまでの閉じた網からの脱却という観点からは非常に大きな出来事です。

既にSoftbankも同様の対応をしていましたが、こちらはiPhoneに限った扱い*2となっており、キャリア提供の全端末で接続回線の制限なくIMAPサーバー公開というのは携帯キャリアで初めての対応ではないでしょうか*3。

各方面で散々指摘されていますが、auのメールシステムはどうやら以前から内部的にはIMAPであったこともあり*4、今回比較的スムーズに公開することができたのかなと思います。ガラケーでもSMSを通知トリガーにした中身はIMAPだったようで、SMS受信後IMAPサーバーにアクセスしてメールを表示、というシステムだったようです。

今回は、ガラケー、あるいはAndroid端末でIMAP認証情報を取得するためのTipsを紹介します。

なお、同様の手順でいわゆる ActiveSync/DirectPush と呼ばれる、Exchange互換のリアルタイム受信（Android端末上の表記はコーポレート同期）を使用することもできます。ただし、この設定を行った場合、iPhone以外の端末では通常のEzメールアプリでの受信はできなくなりますのでご注意ください*5。

手順としては、既にiPhone向けに公になっているSMSによる設定方法とまったく同じです。iPhoneの場合、宛先に #5000 を設定したSMSを送信することで設定用のページを取得することができましたが、ガラケー、もしくはAndroid端末ではこの宛先に送信できないものが多かったため、専用のアドレスに送信することになります。

公式に発表されている手順はこちら。（PDF原本）

1. SMS（宛先: 00090000、内容: 1234）で設定用アドレスを取得
2. 取得したアドレスにUser AgentをiPhoneに偽装して、auの回線（含WiMAX）から接続。接続元は確認されないため、認証情報を取得したい回線とは異なる回線から接続しても問題なし。
3. 設定完了後、認証情報がSMSで送られてくる

たとえばガラケーとAndroid端末の二台持ちの場合、ガラケー宛のメールもAndroid端末で確認したい、という場合、ガラケーからSMSで 00090000 に送信すると設定ページのURLが送られてくるので、そのURLにAndroid端末から接続し、設定に成功すると、ガラケーに認証情報がSMSで送られてくる、という寸法です。

なお、多くのAndroid端末では、アドレスバーに

about:debug

と打ち込んでデバッグモードに移行してやると、設定メニューからUserAgentをiPhoneに変更することが可能ですので、この状態でアクセスするとすんなり設定を行えます。

Docomo Wi-Fi のWISPr対応について

pc, dev |

先日、Docomo Wi-Fi に接続したところ、表記のとおりWISPrプロトコルに対応されていることが確認できました。

これで、国内携帯キャリアが提供する公衆無線LANサービスはすべてWISPrプロトコルに対応したことになります。

対応バージョンは2.0フォーマットで1.0でした*6。WISPr認証情報は初回アクセス時の302 Redirect中の Response Body 内に記載されていたので、 au Wifi と同様ですね。

全キャリア対応のAndroid版WISPr接続アプリをつらつら書いてみたので、そのうち公開するかもですね。

0001softbank、あるいはソフトバンクWi-Fiスポットに関する一考察

dev, pc |

前回のKDDI系Wifiスポットに続き、ソフトバンク版についても認証プロセスを考えてみたいと思います。

結論から言えば、アクセスしてくる端末のUserAgentを見て挙動を変えているという話に帰結してしまうのですが、それだけでは面白みが少ないのでもうちょっと話を広げてみましょう。

ソフトバンクWi-Fiスポット、とは

公式ページはこちら。言わずと知れたキャリアによる公衆無線LANサービスの草分けであり、スポット数は公衆無線LANサービス中でもダントツのトップを誇ります。

しかしながら、絨毯爆撃のような営業に伴って起こっている2.4GHz帯の汚染、またバックホールを1.5GHz帯の自社回線（ULTRA SPEED）としたスポットの増大による回線帯域の無駄遣いという批判*1など、いろいろと問題が提起されているサービスでもあります。

そうはいってもスポット数は圧倒的であり、3G/LTE/WiMAX回線を持たない端末を使う場合には重宝するサービスでもあります。最近ではソフトバンク側もそれを理解しているのか、初代iPadの2年縛り契約がそろそろ終了するのを見越してかソフトバンクWi-Fiスポット(EX)というサービスを始めたりもしています。

サービスの対象には、ソフトバンクモバイルが販売する

• iPhone
• iPad
• Android端末（接続アプリ経由）
• ケータイWifi対応機
• データ通信端末

が挙げられています。

アクセスポイントのSSIDとしては、認証不要の「0001softbank」および偽FONと呼ばれる「FON」に加え、WPA2による認証に対応した「0002softbank*2」が設定されています。これらのAPはソフトバンクモバイルによるものですが、他にも、同じくソフトバンクグループのソフトバンクテレコムが提供する、マクドナルドなどでよく見かける mobilepoint も使うことができるうえ、認証系がソフトバンクモバイル提供のAPと共通となっている為、本稿の内容をそのまま適用することができます。

なお、現在無料体験実施中とのことらしく、パケット定額プランに加入していない端末（一説では電話番号さえあれば良いとか…）でも接続が可能となっています。

iPhone /SoftBankスマートフォン/モバイルデータ通信端末（ソフトバンクWi-Fiスポット対応機種）をご利用でソフトバンクWi-Fiスポットに未加入のお客さまは、期間限定で無料にて体験いただけます。（無料体験は、2012年11月30日迄。当社の都合により無料体験期間を変更する場合があります。）

ご利用いただけるお客さまについて | ソフトバンクモバイル

認証系について

基本的に、すべての認証は w-lan.jp 配下のドメインで行われますが、接続元の端末によって動作が変化します。このため、解析が非常に面倒くさいものとなっています。

APに接続後、任意のページを開こうとすると、0001softbank/FONでは plogin1.pub.w-lan.jp に、mobilepoint では www.login*.w-lan.jp （*は数字）にリダイレクトされ、上記で挙げた対応端末ごとに用意された認証に関するメッセージが表示されます。

なお、mobilepointは各社からのローミングを受け入れている関係上、どのクライアントから接続しても、一応は認証情報の入力画面が表示されます。SoftBank端末からローミングアカウントでのログインも考えられるため、例えばiPhoneで接続していても Yahoo!Wireless のアカウントでログインすることも可能です。以下に示す各パターンは、0001softbank/FONにアクセスした場合のものとお考えください。

iPhoneの場合

UserAgentが

 Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A405 Safari/7534.48.3

の場合。

未認証だと、初期登録を sbwifi.jp で行うよう指示するメッセージが表示されます。このサイトではプロファイルを登録するよう促されますが、認証のキモはその前のページリダイレクトにあります。

iPhone の場合、認証キーの実体は接続ID（Eメール(i)のアドレス）と、パスワードと思われる何らかのハッシュ化文字列をBase64エンコードしたものを含むCookieであり、Safariに対して2038年まで有効なCookieとして埋め込んでいるようです。

Cookieの中身は、

fon.com

MBN=(Strings encoded by BASE64), fonsb=(Hashed strings); Domain=fon.com; Expires=Mon, 18-Jan-2038 15:00:00 GMT; Path=/; Secure

lw.livedoor.com

MBN=(Strings encoded by BASE64); Domain=lw.livedoor.com; Expires=Mon, 18-Jan-2038 15:00:00 GMT; Path=/; Secure

wi2.ne.jp

MBN=(Strings encoded by BASE64); Domain=wi2.ne.jp; Expires=Mon, 18-Jan-2038 15:00:00 GMT; Path=/; Secure

w-lan.jp

MBN=(Strings encoded by BASE64); Domain=w-lan.jp; Expires=Mon, 18-Jan-2038 15:00:00 GMT; Path=/; Secure

という感じです。最後の w-lan.jp 以外はすべてローミングサービス向けのものですが、

fon.com

fonsb は FON_FREE_INTERNET の認証用でしょうが、端末に関わらず固定値になっている気がします。

lw.livedoor.com

Livedoor Wireless向けと思われますが、この提携は本年6月を以て終了している為、今後は使いようがないと思われます。

wi2.ne.jp

ローミングはwi2単独エリアのみ対応しているそうなので、最近急激に増加している au_Wi-Fi との相乗りエリアは対象外と思われます。

という落とし穴が存在します。

また、MBNというCookieのBASE64でエンコードされている部分は

BBMP_iPhone hogehoge@i.softbank.jp (32文字ハッシュ(MD5？))

となっており、これは sbwifi.jp に接続せずとも、UserAgentをiPhoneに偽装して、 mobilepoint に接続・認証に成功すると取得することができます。

なお、ここで挙げた認証情報は結局のところCookieでしかないため、上記のドメインを持つホストに接続した場合、自動的に送信されてしまいます。

ただ、仮に悪意のある0001softbankに偽装したAPに接続し、 w-lan.jp ドメインを持つ偽装サイトにリダイレクトされたとしても、一応、これらのCookieにはSecureフラグがついているので、HTTP接続時には送信されませんし、HTTPS接続だとiPhone側でSSL証明書の相違メッセージが表示されることが予想され、接続者のメールアドレスが攻撃者に流出する可能性は低いと思われます。しかしながら、SSL証明書の相違メッセージをどれだけの人が理解しているのか、という観点から考えると、あまり筋の良い実装とは言い難いのも事実です。

iPadの場合

UserAgentが

Mozilla/5.0 (iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B176 Safari/7534.48.3

の場合。自動認証（おそらくiPhoneと同様の仕組み）に失敗した場合、ログイン用のメールアドレス(i)とパスワードを入力する画面が表示されますので、入力すれば通ります。ただ、契約種別を見ているのか、 iPhone のアカウントでは通らない模様。

Androidの場合

接続用アプリによる接続が必須となりますが、交換機用の暗証番号を入力する必要があること、また導入時に電話番号の読み取り許可が必須となっていることから、電話番号と暗証番号による認証を行っていることが推測されます。

アプリ名にもがっつり jp.co.softbank.wispr.froyo とありますので、WISPrコードを探してみたところ、接続用アプリのUserAgentが

WSP_CLNT;SoftBank/1.0

であると思われたことから、結局、Android端末においてはケータイWifi対応機の認証系を間借りしているのではないか、と推測されました。

ケータイWifi対応機の場合

ケータイWifiとは、ガラケーにWifiチップを積み、3G回線以外に高速回線でネットができるということを売りにしたサービスです。一昔前には各キャリアとも力を入れていましたが、スマホの登場に伴いどんどん縮小しており、docomoに至ってはサービスを終了してしまいましたし、ソフトバンクでも2010年秋冬モデルの004SHを最後に新規機種が発表されていません。

この004SHのUserAgentは、

SoftBank/2.0/004SH/SHJ001/SN（端末シリアル） Browser/NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1

となっています。

このUAに偽装して「0001softbank」にアクセスしてみると、

のようなページが表示されます。このソース中には、

というようにWISPrのコードが記載されており、このURLに Username として電話番号を、 Password として回線暗証番号をPostしてやると、正常に認証が通ります。なお、POST時にもUserAgentを見ているようで、「SoftBank/2.0」などのような文字列を判別できない場合にはログインエラーとなってしまいます。

また、APごとに認証URLが微妙に変化するようですので、決め打ちで実行するのは難しい模様。ちなみに、 mobilepoint でも同様にWISPrコードが表示されるので、同じようにログインが可能です。

これらの結果を受けて、Androidでもこの仕組みを使用しているのであろうことがほぼ確定的となりました。