「ヤフオクでID乗っ取り被害、ヤフーとのトラブルも急増。」記事へのコメント

ヤフオクのURLスキームがhttpなんだけど

[Anonymous Coward]

話題とはずれてしまうかもしれないけど、
この機会に疑問に思ってたので聞いてみたい。

ヤフオク関連のぺージのURLスキームがhttpsじゃなくてhttpなんだけど、これって安全なの？
HTTPSが「WebブラウザとWebサーバの間の通信を暗号化して、盗聴を防いでいるに過ぎない」 [wikipedia.org]ってことぐらいは
知っているけど、ヤフオク内の取引ナビ（出品者・落札者同士で連絡するためのメッセージボード）で
住所や電話番号を送っているので、若干不安がある。

教えて、偉い人。

Re:

[monoblock (34215)]

ちょっと補足的に。
「WebブラウザとWebサーバの間の通信を暗号化して、盗聴を防いでいるに過ぎない」
ってリンク先にも書いてありますが、一応、証明書を用いているわけで、通信相手のサーバが
正当な物であるかのある程度の判断もする事が出来ます。って/.Jでも過去のストーリーで何度も
出てるわけですが・・・オレオレ証明書の問題とか。

で、Yahooが全面的にSSLにしないのはサーバインフラの負荷を鑑みて、でしょうね。
SSLは通常のHTTPよりも処理が重いので･･･
一昔前はサーバのネットワーク上位に設置する"SSLアクセラレータ"なるアプライアンスまで存在してましたよ。
（今も有るのかな？）

Re:

[Anonymous Coward]

>通信相手のサーバが正当な物であるかのある程度の判断もする事が出来ます

ある程度、ていうのはどの程度ですか？
URL に対する本物のサーバであることが証明されるのは知っていますし、
証明書を参照すれば認証局に届け出たサーバ管理者の名前が書かれているのも分かります。
でもサイトの名前と全然違う名前だったり、
あるいはググって見つけた聞いたことのない名前のサイトだったりした場合、
そのサーバが正当な物であるかどうかを、
くれぐれも「本物の」サーバ証明書を持つフィッシングサイト [srad.jp]などではないことを、
どうやったらどの程度

Re:ヤフオクのURLスキームがhttpなんだけど

[monoblock (34215)]

返事が遅くなってすみません。（さすがに会社から投稿というわけにも行かないので）

一般論的な部分は、
こちら [verisign.co.jp]をご覧下さい。

しかし、残念ながら、”「本物の」サーバ証明書を持つフィッシングサイト”などと言う物
に対抗する事は、通常のSSLの機能だけでは無理です。

もちろん、サーバ証明書の発行元を目視で確認後、その発行元の情報を調査し、かつ、既
にその発行方法に問題がある事が公表されている、と言った条件が揃えば、どうもあやし
い、ぐらいの見当は付くかもしれませんが、いちいちそんなことを調べるほど慎重な人な
ど見た事がありませんから、上記ケースでは、事実上SSLの認証機能は無力化されていると
見て良いと思います。

また、上記の件とは別件で、アプリケーション署名用の証明書ですが、2001年にVerisign
が誤って｢Microsoft Corporation｣の署名が入った証明書を個人に発行してしまった事例が
あります。
VeriSign 発行の誤ったデジタル証明書による、なりすましの危険性 (MS01-017) [microsoft.com]

この例などは、MicrosoftまたはVerisignからの公表やパッチの提供が無ければ、目視で
あっても厳密に技術的な意味であっても正規の証明書とまったく区別がつかないでしょう。

SSLのサーバ証明書で証明できるのは、そのサーバ証明書自体が、ブラウザに登録された
ルート証明書の発行元となっている認証局で認証されたか、または、ルート証明書発行
元の認証局に認証された中間認証局が認証した物であるという事です。
じゃあ、その認証局は何を見て認証しているんだ？と言う話になると、それは個別に調べ
るか問い合わせるしか無い、と言う話になってしまうので、”どのような条件で発行され
たか”は不明である、と言えます。

この暗号の仕組み自体が破られ、”技術的に偽造された証明書”が使用された、という例
は聞いた事がありませんので、上記の部分に関してだけは、今のところ確かだと思って良
いんじゃないでしょうか。

また、Flashで作られたログインフォームのSSLに関してですが、私はFlashに明るくないの
でちょろっと調べてみたところ、

1、Flashでログインフォームを実装した場合、サーバとの通信はActionScriptで行う。
2、ActionScriptは、SSLでの通信も素のHTTPでの通信でも、どちらでも指定できる。
3、ActionScriptがどちらのメソッドを利用して通信しているかは、Plugin内のみで決定さ
　 れ、ブラウザには表示されない。
4、ただし、ActionScriptでSSLを指定しているにも関わらず、サーバ証明書に不備があった
　 場合、警告メッセージの表示ではなく、単に動作しないかエラー終了となる。
5、ブラウザのSSL表示機能は、単にFlashファイル（*.swf）がSSLで転送されていれば鍵マー
　 クの表示がなされ、通常のHTTPでswfを転送すれば、鍵マークは表示されない。
　（か、開いたまま）
　 これは、実際にID/PASSがどちらのメソッドで転送されているかとはまったく関係が無い。

と言う事のようです。つまり、そのログインフォームの作者の意思次第であり、それをサイト
のユーザが知るにはパケットキャプチャなどで調査するしか無いようです。
私なら、Flashでログイン画面を実装したサイトの利用は単に見合わせます。
（私自身元々Flashアレルギー気味ですが）

と、言う感じなんですが、合格点はいただけますでしょうか？＞親コメントAC様