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