ソフトバンク携帯の https 接続の仕様変更は致命的脆弱性の解消のため 25
ストーリー by reo
なんにせよ解消されてよかった 部門より
なんにせよ解消されてよかった 部門より
ある Anonymous Coward 曰く、
高木浩光＠自宅の日記によれば、6/30 に実施されたソフトバンクモバイルのガラケー Web ブラウザにおいて https: 接続する際の仕様の変更であるが、実は致命的な脆弱性を解消するものであったようだ。
ソフトバンクモバイルでは、https: サイトへ直接接続するのではなく、サイトへのリンクのすべてが https://secure.softbank.ne.jp/ へ書き換えられ、そこで中継されるという仕様だったのだが、今回の仕様変更でこの機能が廃止されている。ITmedia +D モバイルの記事ではサイト開発の利便性向上のためと書かれているのだが、高木氏の日記にて Gmail の内容や cookie 内容を攻撃者側から取得できてしまうデモが掲載されており、昨年の 6 月にメールと Twitter でソフトバンク側と接触していた経緯まで説明されている。
ソフトバンク側は、一年かかってこの中継機能を廃止したようで、このことは評価できるのだが少々時間がかかり過ぎているような気がしないでもない。
確かに時間はかかったかもしれませんが (スコア:5, 興味深い)
SoftBankなどで公式の課金や認証を運営しているサイトはこちらのアドレスを経由するようになっているわけで
いきなり廃止というわけにはいかない事情もあったと思います。
私が関わった部分だけでもサイトの改修だけでなく紐付けられているDBとの内容（アドレスがかわることで取得できるIDやなんかがかわったりとか）とか、
経路を構築している場合はネットワークの改修も必要になったりかなり多岐に渡ります。
比較的新しいものであればいいのですが、老舗のサイトとかになると一から作り直したほうが早いくらいというところもあったりもしました。
実際問題として諸事情によりこの改修に対応出来ないサイトもあり、申請をすれば継続して従来の方式を取ることも出来たと思います。
一度定着してしまったものを改修するとなるとそれなりのスパンが必要になるのは致し方ないことかと思います。
Re:確かに時間はかかったかもしれませんが (スコア:3, すばらしい洞察)
>SoftBankなどで公式の課金や認証を運営しているサイトはこちらのアドレスを経由するようになっているわけで
>いきなり廃止というわけにはいかない事情もあったと思います。
今回の場合、課金・決済において致命的な問題であったうえ、
利用者への案内なども非常に少ない(ゼロ？)ものでした。
利用者は自衛手段を取る権利も自己チェックを行う権利も与えられなかったわけです。
それを「いきなり廃止というわけにはいかない事情も」で擁護するのは厳しいでしょう。
少なくとも、ソフトバンクの公式発表として
「詳しくは公開できないが、現時点でソフトバンクの回線には脆弱性があり
〜のような問題が考えられます。改修には1年程度かかりますので、
利用者の皆様は（自己防衛策や自己チェック案)を行ってください」
と発表するべきでした。
いっそ「ソフトバンク回線ではhttpsのページには極力つながないほうがいい」
と宣言したってよかったと思います。
それをしなかった以上、今回の件は
ソフトバンクの都合で情報を長く隠蔽し利用者を危険に晒し続けた事例以外ではありえません。
そこでキャリアの事情を察する必要などないでしょう。
Re:確かに時間はかかったかもしれませんが (スコア:1, 興味深い)
CP向けの情報なので公にはできないのでここでいうことはできないのですが・・・。
確かにキャリアの事情を考慮する必要はないですが、httpsを使わないようにするというのは認証の関連からそれはありえないです。
この場合の防御策としてSoftBankのhttpsを使用しないようにするということであれば、既存のIDやアカウント情報や課金情報を全て使えない状態になることが考えられます。
キャリアの事情を察する必要はありませんが、コンテンツプロバイダー側としてはこれらを含めてすぐに変更というのは厳しいのはお分かりいただけるのではないかと思います。
利用者への告知にしても、利用者側では「使用しない」という方法しかとれません。
あくまでキャリア側が対応した上で、さらにコンテンツプロバイダーが対応しないと意味がありません。
改修になぜ1年かかったのかは知る立場にありませんしSoftBankを擁護する気もありませんが、キャリア側だけでなくコンテンツプロバイダー側も含めた構成になっているのでキャリアの事情だけで片付けるのはどうかなと。
#リスクを管理する上で実際にこれでどういった被害が発生したのかも公表してほしいところです
Re:確かに時間はかかったかもしれませんが (スコア:1, 興味深い)
>どうせどんな対策取ったって文句はいうんでしょ?
不備の責任がある主体にはクレームが入ります。
それは当たり前でクレーム自体ゼロを前提にするなんてほうが異常です。
その上で、不備への対応のやり方でクレームの度合いは大きく変わりますよね。
今回の件は最悪の一つでしょう。
>確かにキャリアの事情を考慮する必要はないですが、httpsを使わないようにするというのは
>認証の関連からそれはありえないです。
>
>この場合の防御策としてSoftBankのhttpsを使用しないようにするということであれば、
>既存のIDやアカウント情報や課金情報を全て使えない状態になることが考えられます。
>
>改修になぜ1年かかったのかは知る立場にありませんしSoftBankを擁護する気もありませんが、
>キャリア側だけでなくコンテンツプロバイダー側も含めた構成になっているので
>キャリアの事情だけで片付けるのはどうかなと。
前述の通り、自分は
「SB回線においてhttps通信を行うこと自体がリスクの高いものです、信頼性が破綻しています」
とソフトバンクが宣言したって良かったとは言っていますが、
だからといって
「即https通信を禁止して一切動作しなくすれば良かった」とは言っていません。
上記のような状態でもhttps通信を使わざるを得ない人、使いたい人は使えば良かったでしょうし、
その自由は利用者に与えられても問題ないでしょう。
もし、それで利用者が「不安だ。SB回線でhttpsは通信しないでおこう」と判断し、
CPの売り上げが落ちてしまったり、ソフトバンクから流出したりした分の負債は
ソフトバンクが素直に負えばいいだけです。
システムの管理主体はソフトバンクですから当然ですね。
そこで、ソフトバンクの都合で1年も問題を隠し、
利用者に自己防衛・自己チェックの機会すら与えなかったという事実は変わるものではありません。
たとえCPの立場を鑑みても擁護のしようもないものです。
Re: (スコア:0)
ところで、Softbankのデコードしたサーバーから、自前のコンテンツを置いているサーバーは、専用線ではなく、INTERNET接続だって前提は、本当なのでしょうか。
文句言っている人は確信があるみたいな書き方だけど、専用線で他から見られないなら、httpsをデコードしても何の問題もないはずですよね？
Re: (スコア:0)
Re: (スコア:0)
>ところで、Softbankのデコードしたサーバーから、自前のコンテンツを置いているサーバーは、
>専用線ではなく、INTERNET接続だって前提は、本当なのでしょうか。
>
>文句言っている人は確信があるみたいな書き方だけど、
>専用線で他から見られないなら、httpsをデコードしても何の問題もないはずですよね？
せめてタレコミ文にもある高木氏のサイトくらいは全部読みましょう。
専用線ではありません。
だから高木氏も自分の環境でhttps鯖を立てgmailを対象に実験をして(できて)います。
Re: (スコア:0)
何の脆弱性だったのか、まるで理解してないのでは？
Re: (スコア:0)
Re: (スコア:0, 荒らし)
どうせどんな対策取ったって文句はいうんでしょ?
Re: (スコア:0)
1年間もユーザーを危険にさらしていた時点で叩かれて当然だろ。
「ちゃんと告知していれば目をつぶってやれんこともない」と妥協してるのに何その逆ギレ。
次にお前は (スコア:0)
「クレジットカード番号が漏れたかもしれないならただちに利用者に通知すべき」と言う。
理論としてはそういう話ですよね。PSNとかで情報公開が遅れて責められているのと同じ話。
危険性があって、でも公開してくれていないからユーザー側で自衛策が取れなかったと。
で、あなたは公開すべきでなかったと言うのでしょうか？
＃ クレジットカード番号と違うところは、本件は対策完了以後は被害を受ける人が居なくなること・・・ただし、完了前に情報が漏れていなければの話ですが。
Re: (スコア:0)
針小棒大
Re: (スコア:0)
Re: (スコア:0)
ケータイキャリアはその辺り厳しい目で見られています。
てか、何時ぞやのhTCでのメール非対応程度でどれだけ叩かれたかを見れば、この程度カワイイもんですが。
完全に廃止されたわけではない (スコア:1, 参考になる)
Re: (スコア:0)
ezweb (スコア:0)
まだ使われてるかどうかわからんけど、ezwebもかつては似たような仕組み使ってた。
もっとも、JavaScript対応してないから今のところ問題にならないだろうけど。
(Operaと組み合わせて使えるかどうかは不明)
Re:ezweb (スコア:5, 参考になる)
docomoのmova初期（SSL非対応の502iの頃まで）、auはWAP1.0の頃（今は停波）、SSLをGWで中継していました。ただし、SBMのようにドメインをすり替えてしまうものではなく、[オリジンサーバ]←SSL→[GW]←独自プロトコルor非暗号化→[端末] というように、プロトコルを切り替えていましたので、端末上のドメインは本来のものです。
現在はdocomo（SSL非対応端末を除く）、auともend-to-endのSSLでしか通信していませんので、SBMのような問題はありません。auはauでCookieには別の問題があるのですが（この秋の端末から解消）。
Re:ezweb (スコア:2)
おっと、auはHDMLのページを要求されるとlink by linkにスイッチする [kddi.com]のですね。訂正します。
HDMLはこの秋冬に変換されなくなるので、この機能も終わりになるのでしょうか。
Re: (スコア:0)
> 現在はdocomo（SSL非対応端末を除く）、auともend-to-endのSSLでしか通信していませんので、SBMのような問題はありません。
まあドメインが本来のものになるならゲートウェイを挟んでいても問題は出ませんね。
> auはauでCookieには別の問題があるのですが（この秋の端末から解消）。
その代わりPCサイトブラウザの「IPアドレス帯域」が統合されたことで別の問題が
Re:ezweb (スコア:1)
御意。ただし、詳細が不明なので今のところ具体的に問題視できないという問題が。（公式プロバイダだけに詳細情報開示とかだったら…ぞぞ）
Re: (スコア:0)
> 端末上のドメインは本来のものです。
今は手元に端末がないので記憶違いかもしれないのですが、
おそらく WAP2.0端末で子コメントにあるlink-by-linkの時だと思うのですが、本来のドメインではなかったように思います。
(当時の端末がページのURLを確認できたかどうか定かではなく、証明書の発行先がそうだっただけかもしれません)
追加情報 (スコア:0)
もうちょっとわかりやすいデモ: http://blog.tokumaru.org/2011/07/ssl.html [tokumaru.org]
ゲームとか銀行に影響? http://b.hatena.ne.jp/ockeghem/softbank/ [hatena.ne.jp]
Google Calender (スコア:0)