パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

キャリアによる「通信の最適化」が原因でスマホ向けゲームに不具合が発生」記事へのコメント

  • コンテンツは最適化と言う名の改ざんはできませんよね

    ※できたら大事

    twitterみたいに既にクラウド側で最適化圧縮行うのもあるし

    グーグル先生のサービスはどうなんだろう。

    • by Anonymous Coward on 2015年06月29日 20時48分 (#2838984)

      端末にあらかじめルート証明書入れればできるでしょ

      親コメント
      • by Anonymous Coward

        そりゃ、証明書とURLのチェックでばれるでしょ

        • by Anonymous Coward

          証明書を注意深く見れば分かるけどルート証明書がインストールされているので警告はでないし
          中間者攻撃だからURLは変わらずに送られてくるファイルの内容を改ざんできる

          • by Anonymous Coward

            Firefoxでも駄目なの?
            あれって独自の証明書ストア持ってるよね。

          • by Anonymous Coward

            うそを書くなよ。

            クライアントとサーバー間でセキュアに通信しているんで、
            そのデータを間引きできるわけがない。たとえできたとして
            もサーバー側でエラーになるよ。

            • by Anonymous Coward on 2015年06月30日 0時55分 (#2839111)

              https://www.example.com/ [example.com] と通信するとしよう。
              普通は www.example.com の HTTPS サーバは、信頼されたルート証明機関、たとえばシマンテックへつながる証明書を送ってくる。
              端末(ブラウザ)は、自分が信じる「この証明機関は信頼できる」とされる証明機関であるシマンテックへつながる署名があるから、「現在接続している "www.example.com" と名乗るサーバは本物である」と推定する。

              ここで、キャリアが独自のルート証明書、"Carrier CA" を出荷時に端末の証明書ストアに入れておくとしよう。
              ブラウザは www.example.com と思われるホストと通信をし、最終的に "CAREER CA" へつながる署名を確認した。
              Carrier CA はシマンテック同様に「信頼できる証明機関」だから警告は何も表示しない。
              通信の両端に居る「"www.example.com" のサーバ」も「クライアント(ブラウザ)」も正常に通信できる(何のエラーも発生しない)。

              待て、この通信は本当にセキュアだろうか?

              この通信の実態はこう。
              クライアントは www.example.com につないでいるつもりだったが、実は "Carrier" のサーバと通信している。
              "Carrier" のサーバはクライアントのつもりになって www.example.com と通信をする。
              "Carrier" のサーバで一回デコードしてから暗号をかけなおして送信しているわけ(送受信両方とも)。
              通常ならこういう乗っ取りをやると証明書が信頼されなくなるのでブラウザはエラーを吐くが、 "Carrier CA" は信頼された証明機関なのでブラウザは特に問題ないと判断する。

              さて、キャリアである "Carrier CA" が可逆・不可逆圧縮あるいはもっと悪意のある盗聴をおこなっていた場合、利用者(よほど注意深い利用者以外)は気づくだろうか。

              というのが #2838996 [mobile.srad.jp] や #2838997 [mobile.srad.jp] や Superfish 、証明機関の事故の話。

              親コメント
              • 利用者が直接気付くのは難しいだろうという点は同意しますが、それでも、今ならCertificate Transparency (CT)があるので、Carrier CAが証明書を偽造していることはすぐに発覚するはずです。そのため、現在のいわゆる「通信の最適化」のように黙って実施することはないと期待して良いのではないでしょうか。

                CTが生まれたきっかけも、偽造証明書の事故(DigiNotarのときの)ですし。
                CT(Certificate Transparency:透かし入り証明書)の現状 [digicert.ne.jp]

                この事件が、Googleのエンジニアたちに証明書の偽装に関する新しい解決策の確立を迫りました。Googleは議論の末、ベン・ローリーとアダム・ラングリーという二人のエンジニアが考えたCT(Certificate Transparency:透かし入り証明書)のアイデアを、オープンソース・プロジェクトとして開始しました。

                親コメント
              • by Anonymous Coward

                一個だけある「"CAREER CA"」は「"Carrier CA"」の間違いです。「そこだけ違うから信頼できない」という話ではありません。

            • by Anonymous Coward

              君が問題を理解できていないのはよくわかったから、ちょっと黙っていてくれないか。
              その間に「MITM問題」というキーワードをググって勉強しておいてくれたまえ。

        • by Anonymous Coward
          「SOFTBANK CA」みたいなのが信頼済みルートに入れられ、実際の通信先のホスト名をCommon Nameに持った証明書に入れ替えられて通信されたら警告も出ないし結構気づかないと思う
          • by Anonymous Coward

            キャリア謹製のSuperFish。入れられたら本当に気づかないと思う

          • by Anonymous Coward

            そこでHTTP Public Key Pinningですよ

        • by Anonymous Coward

          OSの提供するAPIにセキュア通信を丸投げしている場合は使われてるルート証明書のチェックとかしない。
          こういう加工をやる場合中間パス含めて差し替え(偽造)用の物を作ってパスも再現したりするし、
          結局アプリが自前で正しい証明書を別の経路で取得してそれと比較するしか無い。
          そしてセキュア通信APIと証明書をゴニョゴニョするなりOpenSSLなり乗っける必要もあるので結構面倒。
          # 当然の話なんだけど同じURLで偽装されるんでURLチェックは無意味です。

          とりあえずこのタイプの事象に限って言うならMIME偽造だのポート番号変更だので対抗したほうが楽かなぁ…

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...