パスワードを忘れた? アカウント作成
2367943 story
インターネット

Webサイトは常時SSLにすべき? 70

ストーリー by hylom
無駄なCookieとPOSTは廃止しよう 部門より
あるAnonymous Coward 曰く、

ITmediaの記事によると、米国でWi-Fiサービス上での中間者攻撃への対策としてWebサイトを常時SSL化すべきだとの提言がなされており、支持が集まっているという。

この提言は2月に行われたセキュリティカンファレンスRSA Conference 2012のセッションで、インターネットサービス企業やセキュリティ企業、米国政府機関などが参加する「Online Trust Alliance」により行われたもの(日本語白書)。背景には、Wi-Fi通信で暗号化されていないセッションを自動的に検出してcookie情報を盗み取る「Firesheep」というツールによる「サイドジャック」という中間者攻撃が発生していることと、近年のWi-Fiサービスの急拡大に伴ってこの対策が求められていることがある。

中間者攻撃への対策としては他にもVPNを用いることなども考えられるが、そうしたユーザー側での対応には限界があり、Webサイト側で対処する方が効果的だとしている。この提言にはGoogleやFacebook, Twitterといった大手企業も賛同の意を示しているという。

SSL化によるパフォーマンス低下や証明書のコストが気になるところであり、またこの提言を行ったOTAにはSSL証明書を販売するVerisignが参加しており、マーケティングの一環ではと思ってしまう面も無きにしも非ずだが……。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Transport Layer Security (TLS) False Start [ietf.org]
    Transport Layer Security (TLS) Snap Start [ietf.org]
    無線環境だと特にラウンドトリップが長いのでこのあたりの技術が使われる様になるんでしょうかね。
    TLS False StartについてはChromeやFirefoxでサポートされているようですし。
    SSL FalseStart Performance Results [chromium.org]

    --
    屍体メモ [windy.cx]
  • by shuichi (572) on 2012年03月30日 17時53分 (#2126844) 日記

    この記事の中間者攻撃の説明おかしくない?
    っと思ったらFiresheepの部分無くしたらおかしくなかった。
    Firesheep、中間者攻撃と関係ないよね?

    • by Anonymous Coward

      Firesheepはいわゆるセッションハイジャックのツールのようで、セッションハイジャックが中間者攻撃かと言われると微妙な気はしてきますが、ベリサインのたぶん同じ話題を扱ったと思われるページ [verisign.co.jp]には、

      Firesheepなどを使った中間者攻撃の特徴と対策をまとめたホワイトペーパー

      という記述があるので、一応広義の中間者攻撃に入っているようです(?)

      • by Anonymous Coward

        広義のセッションハイジャックは第三者がHTTPの向こう側(XSS)、あるいは手前(トロイ?)にいる場合も含む。それに対して、Firesheepの場合は第三者がwifi経由なんだから、中間者って言って差し支えないと思う。最終的な立ち位置が「中間」ぽくはないけれど、侵入(?)経路を考えるとやっぱりMiddleが突破口なんだから。

        というか、暗号化で防げるのは中間者ってことでいいんじゃないかな。中間者攻撃でないと仮定すると、暗号化したって全く効果がないと思うんだけれど。

        • by shuichi (572) on 2012年03月30日 22時03分 (#2126954) 日記

          Firesheepってパケットアナライザだよね?
          中間者攻撃って

          アリス <-------> マロリー <-------> ボブ

          みたいに、攻撃者が通信を中継する攻撃を言うんだと思ってたんだが、
          こういう攻撃も中間者攻撃に含まれるとは思わなかった・・・

          親コメント
          • by Anonymous Coward on 2012年03月31日 4時37分 (#2127047)
            顧客 <-------> 営業 <-------> 技術
            みたいなもんですか。
            親コメント
            • by Anonymous Coward

              顧客 プロマネ 技術
              に一票。
              #ああっ。回りは敵ばかりだっ。

          • by Anonymous Coward

            戦闘前の索敵を攻撃行為に含むかどうか…みたいな。

          • by Anonymous Coward
            ロマリーと空目した
  • 同じIPアドレスでのバーチャルドメイン運用において常時SSL通信化は通常できないのが難点。
    SNIが使える環境なら対応できる [srad.jp]ようですが(例:Apache 2.2.12以降+OpenSSL 0.9.8f以降)、
    XP上ではIE/Safari/Chromeが対応してないとか、やはり常時SSLというのは難しいのかなという気がします。

    ちなみに、先日Firefox/Chromeの標準の接続を全てHTTPSにするアドオン [impress.co.jp]なんてのも話題になってましたけどね。

    • このストーリーは世間一般のウェブサイトの話なのでちょっと話がそれるのですが、
      以前SNIを知らなかった頃、リバースプロキシのpoundでSSLを解いて
      Apacheのバーチャルドメインに渡すという運用をしていました。
      poundには証明書を1つしか設定できないのでワイルドカード証明書の
      適用範囲のホスト名(*.example.comみたいな)しか使用できないという制限があるため
      一般用途には使用できませんが、個人用途ならこんな方法もあるということで。

      # アクセスログの設定を忘れてて全ログがlocalhostになり、すわウィルス感染か! と慌てた思い出が

      親コメント
    • SNIはとても便利だと思うのですが、ブラウザの対応状態が酷くて実際に運用できないですよね。
      ちょっと古い環境なら駄目なら分かるのですが、androidブラウザが非対応っていうのが一番痛い。
      Googleが非対応にしたのが不思議でしょうがない。

      親コメント
  • by iwakuralain (33086) on 2012年03月30日 19時54分 (#2126897)

    怪しいリンクをクリックする人が減るわけでも、メール添付を確認せずに開くひとが減るわけじゃないさ

    とか言ってたら身もふたも無いけどサーバー側だけでは常時SSLってのは難しいな。
    Apacheのバージョンや使い方によっては結構制限されることあるしな~。

    • by Anonymous Coward

      どうせ警告でなきゃドメインなんか気にしないので
      https://example.jp/example.net/path/ [example.jp]にアクセスすると
      → 適切なSSL → example.jpがproxy → HTTP → example.net/path
      ってサービス作ればwifiの中間者攻撃?は何とかなるし、ユーザーも(ほんとは安全じゃないけど)安全に見える!
      ってのはどうだろう!?

      https://example.jp/ [example.jp]の人の信用と、どうやって運用費カバーするのかが問題

  • deep packet inspectionなんてものが登場するかもしれないんだし、
    だったら、主要な通信は SSL にしてしまって、自衛するが一番だと思う。

    http://yro.srad.jp/story/10/05/31/0118203/ [srad.jp]

    #SSLによるCPUコストなどで鯖ベンダやLBベンダとかも原則SSLに協賛してもよさそうな気がするけど、
    #DPIの方が儲かるのかな・・・?w

    --
    by rti.
  • by Anonymous Coward on 2012年03月31日 0時35分 (#2127008)

    > SSL化によるパフォーマンス低下や証明書のコスト

    国内は未だに高コストですが、海外だと値崩れも良いところです。

    下記サイトに至っては、なんと無料です。
    IEやFirefoxなどのメジャーどころはすべて対応しています。

    無料といってもトライアルではなく、1年ごとに継続して発行できます。
    ワイルドカードやEV証明書は有料ですが、それでも格安ですよ。

    http://www.startssl.com/ [startssl.com]

  • http://d.hatena.ne.jp/giugno/20081017/1224233294 [hatena.ne.jp]
    にあるように、SSLでも平文通信というのが可能なようです。
    これを利用者側から見分ける方法というのはあるのでしょうか?

    ある意味、オレオレ証明書よりもひどいと思うのですが。

  • by Anonymous Coward on 2012年03月31日 9時31分 (#2127083)

    事業者が自ら中間者攻撃する始末だからな。

  • by Anonymous Coward on 2012年03月30日 18時10分 (#2126854)

    「暗号化」と「本人である事が安心なのか」はすべて別なのであります!
    フィッシングサイトだってちゃんとSSLを使っているんだしねw
    オレオレ証明書が難無く通る仕組みを作ったうえでSSLの強制化を話してくださいw
    オレオレでも暗号化については”同等に安全”なのは知ってるはずだろう?
    でなければやはり商売の香りがぷんぷんする。

    オレオレを締め出した上に本来のSSLの趣旨であろう企業証明書?が別は枠で出来上がったのはなんでだろうね。

    • by Anonymous Coward on 2012年03月30日 18時20分 (#2126860)

      全く理解できない内容だけど、中間者かなにかに攻撃(頭殴られたとか)されたせいでおかしくなっちゃったんだよね?

      親コメント
      • by Anonymous Coward

        Anonymous Cowardなのだから仕方ないね

    • by DesKwa (35996) on 2012年03月30日 22時47分 (#2126976)

      個人情報を送受信するサイトじゃなければオレオレでもいいと個人的には思います。

      個人情報を流すならちゃんとしたサーバ証明書は欲しいですが、単にデータの送受信であれば
      暗号化目的のオレオレで十分じゃないのかな、と思います。

      通信の秘密を物理的に守る意味でも、ね。

      #ちゃんとした証明書だとサーバ側で金と手間が掛かる、と言うのもありますしね。

      親コメント
    • by Anonymous Coward

      中間者がいる、つまりパケットを盗聴して、変なパケットを送りつけられる、という前提で、オレオレ証明書のサイトはどこの誰だか安心できないっていうのを知った上で?

      • by develop (22404) on 2012年03月30日 20時00分 (#2126901)

        第三種オレオレ証明書であれば
        >中間者がいる、つまりパケットを盗聴して、変なパケットを送りつけられる
        という前提はどうにかなりますネ
        ルート証明書インストールしちゃうと、どんなドメインでも発行できてしまうので所有者を信じていいのか悩みますが…

        親コメント
      • by Anonymous Coward

        その証明書(CA/クライアント/サーバー)が全部オレオレでも、全部自分で作成してあって、
        自分以外が接続しない(させない)サーバーに適用してある分にはまあいいんじゃね。
        自分のサーバー/クライアントとつながってるのは当事者なら分かるだろうし。
        もちろんprivate key等が流出していない前提だけど。

        そんなわけで第三者が接続する必要があるなら真っ当なCAで署名された証明書がいるだろうけど、
        個人や企業内で使用するものに関してもverisign等の証明書使ってないとエラーになるとかいうのは勘弁してくれっていうのは理解できる。

        • by Anonymous Coward on 2012年03月30日 18時48分 (#2126878)

          エラーになるのはverisign等の証明書じゃないからではなく、登録されていない証明書だからですよ。
          個人や企業内で使用するものであれば、自分で証明書をインポートすればエラーはでません [www.idal.jp]。

          なお、真面目にセキュリティを考えるのであれば、インポートする証明書は別途安全な手段で受け渡す必要があります。
          verisign等の登録済みの証明書で運用されているサーバーからダウンロードさせるか、それが出来なければUSBメモリで手渡す等です。
          (セキュアドか何かの情報処理試験でそんな問題を見た覚えもあります。)
          オレオレ証明書のWebページからダイレクトにインポートすることも出来ますが、その場合ドメインが既にすりかえられていた場合に検証できません。

          親コメント
          • by Anonymous Coward on 2012年03月30日 20時23分 (#2126914)

            一応ここに

            (#2126870) だけど、OSなりブラウザなりにインポートできるシステムではあんまり問題じゃないんだ。
            いまならガラケーがインポートできないシステムの筆頭だし、androidも4.0までは(VPN用途以外には)できなかった。
            上記のシステムはverisignのルート証明書等を決め打ちで持ってるけど、
            決め打ちじゃない手法が一般的に可能であるわけじゃないので書いてみた。
            この手法が一般的に可能になるにはインポートを行う側のリテラシが著しく向上しないと無理だろうけどね。

            親コメント
        • by Anonymous Coward

          その証明書(CA/クライアント/サーバー)が全部オレオレでも、全部自分で作成してあって、
          自分以外が接続しない(させない)サーバーに適用してある分にはまあいいんじゃね。

          私も個人的なもので、そういうことをやったことあります。その場合は、OSなりウェブブラウザなりに、オレオレのルート証明書を取り込ませておけば、エラー・警告の類にはならないですよね。

    • by Anonymous Coward

      そのオレオレ証明書が本当にそのサイトのオレオレ証明書であることはどうやって証明されますか?

      • by develop (22404) on 2012年03月30日 20時36分 (#2126919)

        政府認証基盤も第3種または第5種俺俺証明書ですネ

        親コメント
      • by Anonymous Coward
        自明。本当にそのサイト=オレオレだから。自分が繋いでると思ってるサイトとは違うかもしれないけど、オレオレと言ってる誰かに繋がってることは確かなはず。
      • by Anonymous Coward

        フィンガープリントを確認する。

        次にお前は
        「そのフィンガープリントが正しいことはどうやって証明されますか?」
        という!

        • by Anonymous Coward

          で、その答えは?

          • by Anonymous Coward

            フィンガープリントは別の安全な経路で入手するべし

  • by Anonymous Coward on 2012年03月30日 18時27分 (#2126865)

    みんなSSL使うとSSLを使っているので安全ですという説明は、エライ人にはきっと通用しない。

    そうなる前に、HTTP over SSL over SSL で HTTPS を更に暗号化しているので安全です という説明を用意しよう。
    HTTPSSのportは きっと 444 だ。

    証明書は2枚必要ですか?

    • by Anonymous Coward

      > HTTPSSのportは きっと 444 だ。

      snpp 444/tcp # Simple Network Paging Protocol

  • コンテンツ提供側ではなく、ユーザー自信が身を守るべきでVPNサービスやプロクシーサーバサービスみたいなの使えば良いのでは?

  • by Anonymous Coward on 2012年03月31日 0時03分 (#2127004)

    # 気に入らない?自分のスマホ使いなさいよ。

    • by Anonymous Coward

      まぁ、常用されたらコンテンツフィルタリングは難しくなるでしょうな。
      せいぜいが URL フィルタリングになる。

      gateway.example.jp/x?url=http%3A%2F%2Fwww~ とか自社ゲートウェイを必ず最初に中継しなければ出られないようにして、HTML中のリンクを全部書き換えるとかすれば証明書の問題もいけるか?

typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...