secure.softbank.ne.jpの問題が解決に向かいそうなお話
2010年6月17日(木曜日)
secure.softbank.ne.jpの問題が解決に向かいそうなお話
公開: 2010年6月20日16時50分頃
こんなお話が。
- secure.softbank.ne.jp について SoftBank に質問したら残念な結果になったの巻 (co3k.org)
- SSLプロキシの挙動についてソフトバンクモバイル 宮川CTOに何とかしてと頼んだらすぐに何とかなった話 (togetter.com)
前々から懸念していた件が解決しそうで朗報なのですが、モバイルサイトに携わらない人には何の話か分からないと思いますので、少し長くなりますが補足しておきます。
Yahoo!ケータイでWebサイトを見ようとすると、ソフトバンク側のゲートウェイを通ってWebサーバにアクセスすることになります。その際、ゲートウェイでは以下のような処理が行われます。
- HTTP応答ヘッダにx-jphone-uidを付加する (既にx-jphone-uidがついている場合は上書きする)
- 3GC以降の端末でのアクセスの場合、「ウェブコード」で記述された絵文字を「Unicode」の記述に変換する
前者は、いわゆる契約者固有IDを付加する処理です。後者は細かい話になりますが、「絵文字一覧 使用方法 (creation.mb.softbank.jp)」を見ると絵文字の記述方法が2種類あることが分かると思います。実は最近の端末は「Unicode」の方式にしか対応していないのですが、ゲートウェイでの変換処理によって「ウェブコード」で書かれた絵文字が表示できるようになっています。
と、ここでピンと来る方もいらっしゃると思いますが、ケータイサイトを作っていると、「ソフトバンク端末でHTTPS通信時に絵文字が化ける」という現象に出くわす場合があります。
- https:のURLを直打ちしてアクセスした場合に絵文字が化ける
- メール内のhttps:なURLを選択した場合や、QRコードからhttps:なURLを読み取ってアクセスした場合にも同様に文字化けする。
- いったんhttp:でどこかのページにアクセスし、そこからhttps:のリンクを辿った場合には文字化けしない。
絵文字が化けるのは、HTTPS通信時にゲートウェイで通信内容を書き換えることができないからです。先に述べた絵文字の変換処理ができないため、最近の端末で見ると絵文字が文字化けてしまいます。
※「ソフトバンクの絵文字も実体参照で書ける件について (d.hatena.ne.jp)」に書かれているように、数値文字参照で記述すると回避することができるようです。ただし、大規模なケータイサイトではコンテンツ変換サーバが入っていることが多く、簡単には回避策をとれないこともあります。
では、いったんhttp:でアクセスしてからhttps:へのリンクを踏んだときに化けないのは何故でしょうか。その秘密は「WEB & NETWORK SSL/TLS (creation.mb.softbank.jp)」という文書に書かれています。
ソフトバンク3G携帯電話では、「端末⇔弊社GW(以降、GW)」および「GW⇔Webサーバ」の通信区間でそれぞれSSL/TLSのセッションを確立し、GWは「端末⇔Webサーバ」間のSSL/TLSセッションの中継を行います。GWでは、Webサーバのレスポンスに含まれる、XHTMLドキュメント等に記載されたWebサーバへのhttpsリンクを、GWへのリンクに変換します。端末から見た場合、リクエストはGWへのSSLセッションとなります。
Ex: https://www.foo.com/bar.html というURIはGWにて
https://secure.softbank.ne.jp/www.foo.com/bar.html と変換されます。
以上、SSL/TLS より
つまり、いったんhttp:にアクセスした場合は、そこに含まれるhttps:なリンクが書き換えられていて、リンクを辿ると https://secure.softbank.ne.jp/…… というURLにアクセスするようになっているわけです。secure.softbank.ne.jp を通ることで、x-jphone-uidの付加や絵文字のへ変換が行われるようになっています。
この仕組み、x-jphone-uidを使った「かんたんログイン」とは相性が良いのですが、Cookieを使おうとすると問題になってきます。前述のように、URL直接入力やメール、QRコードから来た場合はsecure.softbank.ne.jpを通りません。そのため、ドメインが secure.softbank.ne.jp になる場合とならない場合が出てきてしまい、それぞれ Cookie は別ドメインに発行されたものとみなされてしまいます。
詳しくは述べませんが他にもいろいろまずいことがあって、けっこう困っていたのですね。
そういったわけで、開発者としてはsecure.softbank.ne.jpを使いたくない場合があるのですが、なにしろhttps:なリンクはゲートウェイで全て変換されてしまうので、使わないという選択ができない状態でした。
今回の話では、以下のような対応が検討されているようです。
- 基本的にsecure.softbank.ne.jpの使用をやめて、直接HTTPSで通信が行われるようにする
- 公式サイトのみ、secure.softbank.ne.jpを利用できる選択肢を残す
後者の具体的な方法は不明ですが、ともあれ勝手サイトはsecure.softbank.ne.jpを使えなくなるという方向ですね。絵文字の記述の仕方を変えたりする必要が出てきそうですが、そのあたりは公式なアナウンスが出ることを期待したいところです。
※文中で「QRコード」という語を使っていますが、QRコードは(株)デンソーウェーブの登録商標です。 (www.denso-wave.com)
- 「secure.softbank.ne.jpの問題が解決に向かいそうなお話」へのコメント (2件)
関連する話題: セキュリティ / モバイル / secure.softbank.ne.jp
- 前(古い): 3Dゲームのキモは奥行き
- 次(新しい): 賭博堕天録カイジ 和也編 3