SoftBank SSL仕様変更への対処まとめ

先日、SoftBankのネットワーク環境が変更されるとの通知が行われた。内容はと言うと、2011年2月以降にWebブラウザからSSL通信を行う際の仕様が変更されるというものだ。

果たしてWebサイト側ではどのような対応が必要になるのか？

目次

SoftBankも遂にEnd-to-End SSLへ

SoftBankのSSLは、これまでゲートウェイサーバーを中継する「GW中継SSL」を採用していた。「GW中継SSL」とは、携帯・ゲートウェイサーバー間とゲートウェイサーバー・Webサーバー間とでそれぞれSSL通信が行われる方式のことだ。なぜゲートウェイサーバーを中継していたかというと、次のような機能を実現するためだという。

  • HTTPリクエストへSoftBank拡張ヘッダ（x-jphone-uid等）の追加
  • HTTPリクエストのPOSTデータのキャラクタエンコーディング変換
  • HTTPレスポンスの絵文字をWebコード形式（※1）から数値参照形式（＆#x****;）へ変換
  • HTTPレスポンスのSoftBank拡張ヘッダ（x-jphone-copyright）の処理

※1 エスケープシーケンスを用いて表現する絵文字の書式。SoftBank固有の仕様。

softbank-1

来年2月以降はSSL通信時にはゲートウェイサーバーを中継せず、端末とWebサーバーが直接通信を行う「End-to-End SSL」へと変更される。ということは、これまでゲートウェイサーバーが行っていた上記のありがたい機能は完全に使用不可状態に・・・。softbank-2

SSL仕様変更のワケ

「End-to-End SSL」に変更するメリットはないわけじゃない。

まずはセキュリティの向上。従来はゲートウェイサーバーが一旦SSLを解いていたが、今後は端末とWebサーバー間でSSLが解かれることがない。つまりSoftBankであっても通信内容を傍受したり変更したりすることはできなくなる。

次に「GW中継SSL」方式の場合はブラウザがアクセスするURLが本来のURLと異なるため、本来のドメインで使えるはずのCookieが使えないという問題があった。「End-to-End SSL」への変更により、HTTPで発行したCookieが同一ドメインならSSLでも使えるようになる。

SoftBank側の本心はわからないが、GWサーバー設備を縮小したいという意図もあるかもしれない。GWサーバーは当初、主にロースペックな端末の機能を補助する目的で導入され、携帯Webの進化に伴ってGWサーバーは増強され続けた。が、今やロースペックな2G端末はサービスが終了し、ハイスペックな3G端末のみ。そろそろGW中継SSLは不要なのでは、と判断したのかも。

SoftBank側も市場の要望に応えたとのことなので、将来を見据えれば使いやすい仕様として定着していくのではないだろうか？

新SSL仕様の影響と対応方法

では新しいSSL仕様に変更された際、具体的にどのような影響が想定され、Webサイト側でどのような対応を取るべきなのかをまとめてみた。影響箇所は大きく分けると次の5か所になる。

  1. GW中継時のURLが使用できない
  2. SoftBank拡張ヘッダが取得できない
  3. POSTデータが文字化けする
  4. 絵文字が文字化けする
  5. 著作権保護が機能しない

それぞれについて詳しくみてみよう。

1. GW中継時のURLが使用できない

「GW中継SSL」を使用しているときは、ブラウザが接続するURLは本来とは異なる https://secure.softbank.ne.jp から始まるURLとなる。このURLは2月以降使用できなくなる。例えば、SSLページをBookmarkしてたユーザーが2月以降Bookmarkからアクセスするとエラー画面が表示されてしまう。1月31日の夜24:00前からSSLページにアクセスしているユーザーにも影響が出てしまいそうだ。

真っ当な対策方法はなく、1月31日の夜からSSLページへの入り口を一時的に封鎖するなどして、2月1日0:00前後のアクセスをできるだけ少なくさせる方法しかない。

2. SoftBank拡張ヘッダが取得できない

開発者に一番のダメージを与えるのがコレ！これまで取得できていたUID（x-jphone-uidヘッダ）や描画領域情報（x-jphone-displayヘッダ）などがリクエストヘッダから消滅してしまう。

対処方法としては、HTTPとHTTPSが同一ドメインならHTTP通信時にCookieへUID等を保存する方法がある。HTTPとHTTPSが異なるドメインなら、HTTP通信時に取得した情報をパラメータで引き継ぐといった方法がある。UIDの場合はセキュリティの問題もあって、アプリケーションの大幅な改修になるだろう。

3. POSTデータが文字化けする

コンテンツがEUC－JPもしくはISO-2022-JPの場合にのみ、該当する。従来はゲートウェイサーバーがコンテンツのキャラクタエンコーディングをShift_JISへと変換していたため、POSTデータもShift_JISでWebサーバー側へ送信されていた。新しいSSL方式ではコンテンツのキャラクタエンコーディングが変換されないため、POSTデーのキャラクタエンコーディングもコンテンツと同一となる。

対処策としては、Webサーバー側でPOSTデータのキャラクタエンコーディング指定をEUC-JPあるいはISO-2022-JPへと変更する。ただし、端末側から送信されるAccept-Charsetヘッダから端末側がそのキャラクタエンコーディングに対応しているかどうかをチェックする必要がある。

4. 絵文字が文字化けする

エスケープシーケンス形式（ESC $G! SI等）でHTMLに記述した絵文字は表示できなくなる。

端末側がサポートしてるのは＆#xE001;のような数値参照形式なので、Unicode形式へと記述を変更する。

5. 著作権保護が機能しない

待ち受け画像や着ボイスなどの転送防止にx-jphone-copyrightヘッダを使用している場合、著作権保護機能が動作しなくなる。

対処方法としては、ForwardLock方式でコンテンツを配信するように変更するか、HTTPでコンテンツ配信するように変更する。なお現在HTTPでコンテンツを配信している場合でも、https://～ から始まるURLでコンテンツにアクセスできてしまう環境の場合は要注意。著作権保護されないファイルがダウンロードできてしまうので、SSLでは待ち受け画像や着ボイスにアクセスできないように設定変更が必要だ。

まとめ

End-to-End SSLへの切り替えに伴う変更点は以下の通り。

項目 2011年1月末まで 2011年2月以降
GW中継SSLのURL
（https://secure.softbank.ne.jp）		 アクセス可 アクセス不可
x-jphone-uidなど 取得可 取得不可
POSTデータのキャラクタエンコーディング
（コンテンツがEUC-JPの場合）		 Shift_JIS EUC-JP
POSTデータのキャラクタエンコーディング
（コンテンツがISO-2022-JPの場合）		 Shift_JIS ISO-2022-JP
エスケープシーケンス形式の絵文字 表示可 文字化け
x-jphone-copyright 著作権保護有効 著作権保護無効

影響箇所がある場合はコンテンツ側の対応も大変だが、おそらく切り替え当日まで新しい環境でのテストができないのも困る。結局、2月1日にサイト停止せざるを得ないケースもあるんじゃないか？

ちなみにSSP（SoftBank Solution Provider）認定企業に限り、申請すれば2月以降も「GW中継SSL」を利用できるようだ。SSP認定企業ならこの方法も選択肢に入れて対処できる。

（関連エントリー）

（参考）

Page Top