Webサイトは常時SSLにすべき？ 70
ストーリー by hylom
無駄なCookieとPOSTは廃止しよう 部門より
無駄な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が参加しており、マーケティングの一環ではと思ってしまう面も無きにしも非ずだが……。
TLS False StartとかSnap Startとか (スコア:2)
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]
中間者攻撃？ (スコア:2)
この記事の中間者攻撃の説明おかしくない？
っと思ったらFiresheepの部分無くしたらおかしくなかった。
Firesheep、中間者攻撃と関係ないよね？
Re: (スコア:0)
Firesheepはいわゆるセッションハイジャックのツールのようで、セッションハイジャックが中間者攻撃かと言われると微妙な気はしてきますが、ベリサインのたぶん同じ話題を扱ったと思われるページ [verisign.co.jp]には、
という記述があるので、一応広義の中間者攻撃に入っているようです（？）
Re: (スコア:0)
広義のセッションハイジャックは第三者がHTTPの向こう側(XSS)、あるいは手前(トロイ？)にいる場合も含む。それに対して、Firesheepの場合は第三者がwifi経由なんだから、中間者って言って差し支えないと思う。最終的な立ち位置が「中間」ぽくはないけれど、侵入(?)経路を考えるとやっぱりMiddleが突破口なんだから。
というか、暗号化で防げるのは中間者ってことでいいんじゃないかな。中間者攻撃でないと仮定すると、暗号化したって全く効果がないと思うんだけれど。
Re:中間者攻撃？ (スコア:3)
Firesheepってパケットアナライザだよね？
中間者攻撃って
アリス <-------> マロリー <-------> ボブ
みたいに、攻撃者が通信を中継する攻撃を言うんだと思ってたんだが、
こういう攻撃も中間者攻撃に含まれるとは思わなかった・・・
Re:中間者攻撃？ (スコア:1)
みたいなもんですか。
Re: (スコア:0)
顧客 プロマネ 技術
に一票。
＃ああっ。回りは敵ばかりだっ。
Re: (スコア:0)
戦闘前の索敵を攻撃行為に含むかどうか…みたいな。
Re: (スコア:0)
バーチャルドメインでの運用 (スコア:2)
同じIPアドレスでのバーチャルドメイン運用において常時SSL通信化は通常できないのが難点。
SNIが使える環境なら対応できる [srad.jp]ようですが（例：Apache 2.2.12以降＋OpenSSL 0.9.8f以降）、
XP上ではIE/Safari/Chromeが対応してないとか、やはり常時SSLというのは難しいのかなという気がします。
ちなみに、先日Firefox/Chromeの標準の接続を全てHTTPSにするアドオン [impress.co.jp]なんてのも話題になってましたけどね。
Re:バーチャルドメインでの運用 (スコア:1)
このストーリーは世間一般のウェブサイトの話なのでちょっと話がそれるのですが、
以前SNIを知らなかった頃、リバースプロキシのpoundでSSLを解いて
Apacheのバーチャルドメインに渡すという運用をしていました。
poundには証明書を1つしか設定できないのでワイルドカード証明書の
適用範囲のホスト名(*.example.comみたいな)しか使用できないという制限があるため
一般用途には使用できませんが、個人用途ならこんな方法もあるということで。
# アクセスログの設定を忘れてて全ログがlocalhostになり、すわウィルス感染か! と慌てた思い出が
Re:バーチャルドメインでの運用 (スコア:1)
SNIはとても便利だと思うのですが、ブラウザの対応状態が酷くて実際に運用できないですよね。
ちょっと古い環境なら駄目なら分かるのですが、androidブラウザが非対応っていうのが一番痛い。
Googleが非対応にしたのが不思議でしょうがない。
Re:バーチャルドメインでの運用 (スコア:1)
少なくともXPでは無く、ChromeというかGingerbreadで非対応でした。
モバイルの場合にはバージョンアップもされない事が多いから、今ある端末のほとんどが非対応とみないといけません。
今のIE6並にしつこく残る可能性だってあります。
それに今って対応になりましたっけ？
SSLにしても (スコア:2)
怪しいリンクをクリックする人が減るわけでも、メール添付を確認せずに開くひとが減るわけじゃないさ
とか言ってたら身もふたも無いけどサーバー側だけでは常時SSLってのは難しいな。
Apacheのバージョンや使い方によっては結構制限されることあるしな～。
Re: (スコア:0)
どうせ警告でなきゃドメインなんか気にしないので
https://example.jp/example.net/path/ [example.jp]にアクセスすると
→ 適切なSSL → example.jpがproxy → HTTP → example.net/path
ってサービス作ればwifiの中間者攻撃？は何とかなるし、ユーザーも(ほんとは安全じゃないけど)安全に見える！
ってのはどうだろう！？
https://example.jp/ [example.jp]の人の信用と、どうやって運用費カバーするのかが問題
Re:SSLにしても (スコア:1)
似たようなことをソフトバンクモバイルがやって、この間
みずほ銀行が貧乏くじ引かされていた [srad.jp]じゃないですか。
Re: (スコア:0)
proxy と実サーバ間で中間者攻撃（またはただの盗聴）されたら、ユーザが安全だと思ってる分何もしないより危険
deep packet inspection対策 (スコア:1)
deep packet inspectionなんてものが登場するかもしれないんだし、
だったら、主要な通信は SSL にしてしまって、自衛するが一番だと思う。
http://yro.srad.jp/story/10/05/31/0118203/ [srad.jp]
#SSLによるCPUコストなどで鯖ベンダやLBベンダとかも原則SSLに協賛してもよさそうな気がするけど、
#DPIの方が儲かるのかな・・・？w
by rti.
証明書コスト (スコア:1)
> SSL化によるパフォーマンス低下や証明書のコスト
国内は未だに高コストですが、海外だと値崩れも良いところです。
下記サイトに至っては、なんと無料です。
IEやFirefoxなどのメジャーどころはすべて対応しています。
無料といってもトライアルではなく、1年ごとに継続して発行できます。
ワイルドカードやEV証明書は有料ですが、それでも格安ですよ。
http://www.startssl.com/ [startssl.com]
SSLでも平文通信 (スコア:1)
http://d.hatena.ne.jp/giugno/20081017/1224233294 [hatena.ne.jp]
にあるように、SSLでも平文通信というのが可能なようです。
これを利用者側から見分ける方法というのはあるのでしょうか？
ある意味、オレオレ証明書よりもひどいと思うのですが。
コネクトフリーとかセブンアンドアイとか (スコア:1)
事業者が自ら中間者攻撃する始末だからな。
そもそも・・・ (スコア:0)
「暗号化」と「本人である事が安心なのか」はすべて別なのであります！
フィッシングサイトだってちゃんとSSLを使っているんだしねｗ
オレオレ証明書が難無く通る仕組みを作ったうえでSSLの強制化を話してくださいｗ
オレオレでも暗号化については”同等に安全”なのは知ってるはずだろう？
でなければやはり商売の香りがぷんぷんする。
オレオレを締め出した上に本来のSSLの趣旨であろう企業証明書？が別は枠で出来上がったのはなんでだろうね。
中間者攻撃こわい (スコア:1)
全く理解できない内容だけど、中間者かなにかに攻撃(頭殴られたとか)されたせいでおかしくなっちゃったんだよね？
Re: (スコア:0)
Anonymous Cowardなのだから仕方ないね
Re:そもそも・・・ (スコア:1)
個人情報を送受信するサイトじゃなければオレオレでもいいと個人的には思います。
個人情報を流すならちゃんとしたサーバ証明書は欲しいですが、単にデータの送受信であれば
暗号化目的のオレオレで十分じゃないのかな、と思います。
通信の秘密を物理的に守る意味でも、ね。
＃ちゃんとした証明書だとサーバ側で金と手間が掛かる、と言うのもありますしね。
Re: (スコア:0)
中間者がいる、つまりパケットを盗聴して、変なパケットを送りつけられる、という前提で、オレオレ証明書のサイトはどこの誰だか安心できないっていうのを知った上で？
Re:そもそも・・・ (スコア:1)
第三種オレオレ証明書であれば
>中間者がいる、つまりパケットを盗聴して、変なパケットを送りつけられる
という前提はどうにかなりますネ
ルート証明書インストールしちゃうと、どんなドメインでも発行できてしまうので所有者を信じていいのか悩みますが…
Re: (スコア:0)
その証明書(CA/クライアント/サーバー)が全部オレオレでも、全部自分で作成してあって、
自分以外が接続しない(させない)サーバーに適用してある分にはまあいいんじゃね。
自分のサーバー/クライアントとつながってるのは当事者なら分かるだろうし。
もちろんprivate key等が流出していない前提だけど。
そんなわけで第三者が接続する必要があるなら真っ当なCAで署名された証明書がいるだろうけど、
個人や企業内で使用するものに関してもverisign等の証明書使ってないとエラーになるとかいうのは勘弁してくれっていうのは理解できる。
インポートすればエラーでないよ (スコア:2, 参考になる)
エラーになるのはverisign等の証明書じゃないからではなく、登録されていない証明書だからですよ。
個人や企業内で使用するものであれば、自分で証明書をインポートすればエラーはでません [www.idal.jp]。
なお、真面目にセキュリティを考えるのであれば、インポートする証明書は別途安全な手段で受け渡す必要があります。
verisign等の登録済みの証明書で運用されているサーバーからダウンロードさせるか、それが出来なければUSBメモリで手渡す等です。
（セキュアドか何かの情報処理試験でそんな問題を見た覚えもあります。）
オレオレ証明書のWebページからダイレクトにインポートすることも出来ますが、その場合ドメインが既にすりかえられていた場合に検証できません。
Re:インポートすればエラーでないよ (スコア:1)
一応ここに
(#2126870) だけど、OSなりブラウザなりにインポートできるシステムではあんまり問題じゃないんだ。
いまならガラケーがインポートできないシステムの筆頭だし、androidも4.0までは(VPN用途以外には)できなかった。
上記のシステムはverisignのルート証明書等を決め打ちで持ってるけど、
決め打ちじゃない手法が一般的に可能であるわけじゃないので書いてみた。
この手法が一般的に可能になるにはインポートを行う側のリテラシが著しく向上しないと無理だろうけどね。
Re: (スコア:0)
私も個人的なもので、そういうことをやったことあります。その場合は、OSなりウェブブラウザなりに、オレオレのルート証明書を取り込ませておけば、エラー・警告の類にはならないですよね。
Re: (スコア:0)
そのオレオレ証明書が本当にそのサイトのオレオレ証明書であることはどうやって証明されますか？
Re:そもそも・・・ (スコア:1)
政府認証基盤も第3種または第5種俺俺証明書ですネ
Re: (スコア:0)
Re: (スコア:0)
フィンガープリントを確認する。
次にお前は
「そのフィンガープリントが正しいことはどうやって証明されますか？」
という！
Re: (スコア:0)
で、その答えは？
Re: (スコア:0)
フィンガープリントは別の安全な経路で入手するべし
みんな安全なんてありえない (スコア:0)
みんなSSL使うとSSLを使っているので安全ですという説明は、エライ人にはきっと通用しない。
そうなる前に、HTTP over SSL over SSL で HTTPS を更に暗号化しているので安全です という説明を用意しよう。
HTTPSSのportは きっと 444 だ。
証明書は2枚必要ですか？
Re: (スコア:0)
> HTTPSSのportは きっと 444 だ。
snpp 444/tcp # Simple Network Paging Protocol
「Wi-Fiサービス上での中間者攻撃への対策として」だけなら (スコア:0)
コンテンツ提供側ではなく、ユーザー自信が身を守るべきでVPNサービスやプロクシーサーバサービスみたいなの使えば良いのでは？
Re: (スコア:0)
Proxyじゃ防げないだろ？
Re:「Wi-Fiサービス上での中間者攻撃への対策として」だけなら (スコア:1)
なんで？
監視する側としては(ry (スコア:0)
# 気に入らない？自分のスマホ使いなさいよ。
Re: (スコア:0)
まぁ、常用されたらコンテンツフィルタリングは難しくなるでしょうな。
せいぜいが URL フィルタリングになる。
gateway.example.jp/x?url=http%3A%2F%2Fwww～ とか自社ゲートウェイを必ず最初に中継しなければ出られないようにして、HTML中のリンクを全部書き換えるとかすれば証明書の問題もいけるか？
Re:難しい話はよくわからないけど (スコア:1)
何でもかんでも、原発に結びつけてウゼー
しかも全く結びついてないし。
♯個人的にはサーバ側の対応が結構面倒そう。
♯それ以前にビッグブラザー的な国は困るだろうね。
Re: (スコア:0)
文部科学省の副読本がデタラメだらけだったので、回収した [msn.com]ということも知らんのか。
しっかし、「わくわく原子力ランド」、「チャレンジ！原子力ワールド」ってブラックなネーミングだなｗ
Re: (スコア:0)
あなたはその副読本を読んで信じたと言っているのですか？
違いますよね。論点をずらしてもつまらないですよ。
Re:難しい話はよくわからないけど (スコア:2)
あなたはその副読本を読んで信じたと言っているのですか？
違いますよね。論点をずらしてもつまらないですよ。
> 「原発は絶対安全です」なんて事を何度も言ったキチガイの名を晒してくれますか？
に対するコメントだろう。おまえこそ論点ずらすな。
Re: (スコア:0)
どうして東電はたった1回事故起こしただけで実質国有化まで追い込まれてるんですか? まさかどっかのキチガイが絶対安全といったことをまに受けたわけないよね。
Re:SSLアクセラレーターは必須。そう考えていた時代が（ｒｙ (スコア:1)
スマートフォンなどのバッテリ持続に影響しないかとちょっと心配。
別の問題かも知れないですけど3GでPPTP通信有効にするとバッテリの消費が加速しますので。
armにAES-NI的な物はあるのかな？ 使う側が対応しなきゃ無意味か。