by
Anonymous Coward
on 2005年10月23日 14時53分
(#819140)
他者と言っても、この場合、内容を入れ換える可能性があるのは Microsoft なわけです。 もし Microsoft を信頼できないと仮定するなら、問題のある 証明書のインストールなんてまどろっこしい手を使わなくても、 Microsoft には、いくらでもあなたに対して不正を働く手段が あります。(Microsoft が不正を働いているという意味では全く ありません。技術的にそれが可能だという意味です。)
もし Microsoft を信頼できないと仮定するなら、そもそも Microsoft 製の OS やアプリケーションを利用してはいけません。 (たとえ Apple の OS を利用していても、Microsoft Office を その上で利用していれば、同程度のリスクがあります。)
Microsoft の OS やアプリケーションを利用しているのであれば、 証明書の信頼性について Microsoft の判断を信頼するのは、許容 できる範囲のリスクなのでは?
IEには、中間認証局の証明書をAuthority Information Access拡張フィールドの値を頼りにそこから自動でダウンロードして検証する機能があるのに対して、Mozillaにはそれがないようです。そのため、Microsoftのサイトでは、証明書チェインに中間認証局の証明書を同梱していないサイトが多数見られます。
「どのようにすれば証明書が発行してもらえるか」というような証明機関の運用規則は，CPS（Certification Practice Statement）という文書にまとめてあります。証明機関はCPSを公開することが各種の規格で義務付けられており，ブラウザにルート証明書が同梱されているような証明機関ならば必ず何らかの方法で閲覧できるようになっています。
問題ないったら問題ないんだよ (スコア:3, おもしろおかしい)
Re:問題ないったら問題ないんだよ (スコア:2, おもしろおかしい)
釣り天国 (スコア:3, おもしろおかしい)
BIGLOBE 釣り天国 お魚コレクション [biglobe.ne.jp] というページ。
ログイン画面なのだが、そこにこんな案内が書いてある。
まさに釣り天国。証明書の取らせかた (スコア:2, 興味深い)
この手の隙をついた攻撃があまり無いから具体例として被害の例も挙げることが出来ないですし、イマイチ良い説得方法が見付かりません。
...みなさんどうやって説得してるんですかね？
Re:証明書の取らせかた (スコア:4, 参考になる)
Re:証明書の取らせかた (スコア:2, 参考になる)
VodaとかDoCoMoだと、ダイアログでいけちゃったとおもいます。
Re:証明書の取らせかた (スコア:2, 参考になる)
＃ auの携帯を持ってるひとは試してみよう。
＃ トップメニュー → 「4.ライフ」 → 「バンキング・マネー」 → 「都市銀行」 → 「三井住友銀行」
Re:証明書の取らせかた (スコア:2, 参考になる)
を用意して、できるだけ決済権に近い人の目の前でテストすることができれば、警告が表示されたときに戸惑う様を見せることができます。
というか、たいてい決裁権者は初心者なので、まともなブラウザや IE でも安全な設定で使わせて、警告を見せることができれば「かっこ悪い」と感じると思います。「なんだこの邪魔くさい感じは」と思わせれば少し道が開けるんじゃないでしょうか。
Re:証明書の取らせかた (スコア:1, 興味深い)
Re:証明書の取らせかた (スコア:4, 参考になる)
他にもhostsファイルが改ざんされたとか、ブラウザのバグをやられたとか。
アドレスバーはあくまで目安で本当は何処にどのように繋がってるかなんて解らないんです。
その途中の経路も含めて保障してくれるのが正しく運用されたSSLなんですけど。
Re:証明書の取らせかた (スコア:2, 興味深い)
このような本家だかそうだかわからないアドレスは簡単に取れてしまいます。
次に最近でもいろいろな商業サイトがトップページ以外のリンク先が別ドメイン名になっていることは珍しくありません。表示されたアドレスを見ているとむしろアドレスでは判断できないと感じます。
そして例えアドレスが本物が表示されていたとしても、ルーティング情報を攻撃されていれば本物のアドレスから偽のサイトに誘導されます。最近のウィルスにそういう攻撃をするものがあったはずです。
URLアドレスだけで危険性を判断するのでは、オレオレ証明書を信用したとたんにフィッシング詐欺に騙されるわけです。
＃各セキュリティ認証機関は速やかにNTT西日本の認証を取り下げるべきだと思います
Re:証明書の取らせかた (スコア:2, 参考になる)
> 使っているフィッシングサイト？が、www.au-kddi.comです。
残念ながら、www.au-kddi.comというURLアドレスから
危険性を判断できない人は、オレオレ証明書を信用しない
というだけでは、やはり騙される恐れがあります。
なぜなら、「www.au.kddi.comの偽物だから正しい証明書は
取れない」のではなくて「本物のwww.au-kddi.comとして
正しい証明書が取れる」からです。
正しい証明書からはそのサイトが本物のauなのか判断する
ことはできますが、その為には詳細を開いて確認するときに
あらかじめ「本物のauであればどう書かれているのか」を
知っておかなければならないでしょう。
# > トップページ以外のリンク先が別ドメイン名になっている
# こういうこと [asahi-net.or.jp]されるとかなりゲンナリ。
Re:証明書の取らせかた (スコア:1, 参考になる)
Re:証明書の取らせかた (スコア:1, おもしろおかしい)
しかしサーバー側がアドレスバーを消してしまった。
どうしますか？
１．帰る
２．文句を言う
３．うろたえる
Re:証明書の取らせかた (スコア:1, 参考になる)
部門サーバー群の一部が落ちた事をアナウンスする時とかどれが見れてどれが見えないのかってのを何度も何度も聞かれますし。
# そのサーバーでは Web サーバー上げて無くても聞かれたり。
いや、まず盗聴が問題というのは確かですが。
Re:証明書の取らせかた (スコア:1)
DNSまで偽物捕まされますし、、、
uxi
Re:証明書の取らせかた (スコア:1)
詳しい図解入りの説明書作ったって良いだろうし、解説しているサイトに誘導するのでも良いのでは？
口で言ってまくし立っても、それをイメージ出来ていない奴がぱっとイメージ出来る訳ないよ。
言われた方が上司を説得するにしても、資料が無いと説明し難いだろうし。
Re:証明書の取らせかた (スコア:2, 興味深い)
素人であるユーザーにとってはどういう経緯で証明書が発行されていようが、そんなことはどうでもいいわけですから、そこら辺が現場の腕の見せ所なんでしょう。
Re:上司の承認プロセスにおけるマーフィーズロウ (スコア:3, すばらしい洞察)
しかも、その階層図は２ヶ月後にはあてにならなくなる。
・上司の技術的バックボーンが異なり、畑違いの言葉で説明をつけたすため
伝言ゲームでのやりとりをすると、必ず意味合いが変わってしまう。
・技術説明ミーティングを開けば良く集まり、よく理解したような手ごたえがある。。
しかし、必ず後で倍のフォローが必要になる。
・技術的説明が必要な人間は必ず同じフロアにいない。
そういう人間が会議に出たときに限って機材が原因不明のトラブルに遭う。
・すべての承認を取り付けたと一息ついた所で
別部門に対して同じプロセスが必要だと知らされる。
（振り出しにもどる）
この条件に当てはまる数が多いほど、そのプロジェクトが
正月休み等のイベントを台無しにする可能性が高いです。
気をつけましょう。
Re:証明書の取らせかた (スコア:3, おもしろおかしい)
だから証明書の購入コストってのは全然大したこと無いと思います。
ただ、証明書の値段そのものよりも、期限切れの証明書を保守し続けるコストの方が気になります。
一つのプロジェクトで最初にかかるコストが数千や数万円かかるくらいはたいしたことがないと思います。
でも証明書の更新ってのは1年後か長くても数年後には確実に来るものです。
そしてその頃当時のメンバー（特に証明書のことをきちんと分かっている人）が居るかどうかは分かりませんし、更新時期にはプロジェクトに全く関係の無い人間しか居ないこともざらかと思います。
プロジェクト開始時には何の問題も無かったのに、分かる人が居ないかも知れない未来に託して、期限切れが放置されて客からクレーム(第3者から騒がれたとか、突然ダイアログが出るようになったとか)を受けて、自分たちのプロジェクトに泥が付くというのはやりきれないでしょう。
きちんとした運用マニュアルを作ってその通り運用すれば良いと言う意見も当然ですが、そうすることが出来ないケースも多いでしょうし。
そこで「暗号化はされますがサイトの身分証明は出来ないので第3者に誘導された場合の改竄や盗聴の防止にはなりません。それにダイアログも当然出るのでユーザにOKボタンを押して貰うことになります。」
ということを顧客に説明して一度妥協してオレオレ証明書でスタートしてさえしまえば、
後に証明書の期限切れになったとしても、ダイアログが出たらOKを押して進めるというのに慣れたユーザはそのダイアログに期限切れの注意マークが増えていることに気づくことも無くクレームはおきにくい。
という保守コストも削れる駄目駄目な楽チン解の方が良いということも多いでしょう。
技術者ってのは当面のコストよりも将来の保守を嫌う傾向があるようですし…。
なので証明書のコストを議論する際は、証明書1枚の値段よりも証明書の更新の簡単さ(出来れば人が何もしなくても自動更新できると嬉しい)が必要だと思ってます。
Re:証明書の取らせかた (スコア:2, 参考になる)
それだけではなく、運用の厳密さは私の関わっていた金融関連(金融機関のシステムは金融庁のガイドラインでかなり細かく運用方法が縛られている)のシステムとも比べものになりません。
私はとても同じとはいえませんね。
実は (スコア:2, 参考になる)
uxi
盗聴される？ (スコア:1)
自認証局による証明書だって*暗号化には*問題ないんじゃ？
# 「オレオレ証明書」って初めて聞いたのでAC
Re:盗聴される？ (スコア:3, 参考になる)
Re:盗聴される？ (スコア:1, 参考になる)
中継せずに情報を盗む形の悪用もあるよね。盗聴といってしまうと、そういうのが抜け落ちちゃうでしょ。
今回の問題点は「盗聴」と呼ぶより、「なりすまし」と言った方が誤解を招かないと思う。
Re:盗聴される？ (スコア:2, 参考になる)
# だいたい、安全か否かなんてのは程度の問題であって、
# 素のHTTP>オレオレ証明書を使ったHTTPS>マトモなHTTPS>通信しない
# といった風に段階的に危険度が上がっているに過ぎないんだよなぁ。
そもそも「エンドユーザーがルート証明機関を評価して選択しなければならない（しかも評価のための情報が豊富でない）」というSSLの仕様が一番の問題なんでしょうね。
# だからといって他にどうすればいいという考えもないけど。
yp
Re:盗聴される？ (スコア:2, 参考になる)
オレオレ証明書の問題点は自身が証明書を作成しているので信頼性がない点でしょう。
暗号化は行われておりますが、証明書に信頼性がないため、このような証明書を信頼する癖をつけてしまうと簡単にフィッシングサイトに騙されます。
安全のため、NTT西日本とはお付き合いをやめましょう。:-)
違います (スコア:3, 参考になる)
Re:もうちょっと流行ったら (スコア:3, おもしろおかしい)
私がオリジナリティを付加して発表したものとかいう
騒動が起きるとか起きないとかいうデジャヴ。
＃んなこたない
Re:盗聴される？ (スコア:2, すばらしい洞察)
そう認識されちゃうことが問題。
Re:盗聴される？ (スコア:2, すばらしい洞察)
ルート認証機関に認証してもらう必要がなければ誰にでも「NTT西日本」と名乗れるわけですから。
というかリンク先読んでください。
Re:盗聴される？ (スコア:1, すばらしい洞察)
通信路上で改竄されたら、盗聴されますよ。
Re:盗聴される？ (スコア:2, すばらしい洞察)
Re:盗聴される？ (スコア:3, 参考になる)
私は、セキュリティー初心者ですが興味があったので、結城浩著の『暗号技術入門 ―― 秘密の国のアリス』 [hyuki.com]を買いました。
中間者攻撃の怖さと”信頼できる”証明書取得の必要性が、わかりやすい話と豊富な図で解説されているので、 すごくためになりました。
本人の弁 (スコア:2, 参考になる)
ご本人の日記 [hyuki.com]より。
# こんな事で命を取らんでも…
Re:盗聴される？ (スコア:1)
こういう場合は俺様認証局っていうことが多いわな。
Re:盗聴される？ (スコア:1, 参考になる)
で、暗号化の時にどのような手段をとるかは、復号できないといけないから、あらかじめ通信相手と決めておく必要がありますよね。
今回は証明書の信頼性が問題で、誰が通信相手かはっきりわからないことだと思います。
誰かわからない通信相手＝他者の可能性がある時点で、暗号化という言葉の利用は適切でないと思います。
NTT西日本以外に知られたくない情報を、別の他者とやりとりする状況が考えられるわけですよね。
問題はどこに？ (スコア:2, 参考になる)
NTT西日本に、連絡をとりたい顧客が「SSLなんか使わなくっても平文でもいいよ」と思って連絡する場合には問題にならないでしょう。しかし「うちはSSL使っているから安心ですよ」と説明しているというのは、不誠実な対応だと考えます。
# ま、SSLを使っているという一点だけを見ると嘘ではないですが
Copyright (c) 2001-2014 Parsley, All rights reserved.
他者に内容を入れ替えられてしまうキーストアのルート証明書は信頼できるのか (スコア:1, 興味深い)
信頼できない点なわけで、そういう意味では
WindowsUpdateなどで運ばれてくるMicrosoft
が認証した証明書群に無条件でトラストアンカーを
設置してしまうというのも「なんだかな～」と
思ってしまいます。
とはいいつつも、エンドユーザが例えばベリサインの
CPShttp://www.verisign.co.jp/repository/CPS/ [verisign.co.jp]
なんて読まないのだから、それよりはずっとましなんでしょうが。
いい落としどころなんですかね？
皆さんはどうお考えですか。
Re:他者に内容を入れ替えられてしまうキーストアのルート証明書は信頼できるのか (スコア:2, すばらしい洞察)
真正性だなんて自分では検証したことが無いよ。
というか、(例えば)MSの証明書ってどこで検証できるのかな?
工場から出荷されるCD-ROMが本物であるとか、倉庫番が
悪さしないとか、留守に配達を受け取ってくれた家族だ
とか、結局、信用の強度としてはどの辺りだか物理世界の
ずっと弱いところに依存してるんじゃないか知らん。
Re:他者に内容を入れ替えられてしまうキーストアのルート証明書は信頼できるのか (スコア:2, すばらしい洞察)
Microsoft なわけです。
もし Microsoft を信頼できないと仮定するなら、問題のある
証明書のインストールなんてまどろっこしい手を使わなくても、
Microsoft には、いくらでもあなたに対して不正を働く手段が
あります。(Microsoft が不正を働いているという意味では全く
ありません。技術的にそれが可能だという意味です。)
もし Microsoft を信頼できないと仮定するなら、そもそも
Microsoft 製の OS やアプリケーションを利用してはいけません。
(たとえ Apple の OS を利用していても、Microsoft Office を
その上で利用していれば、同程度のリスクがあります。)
Microsoft の OS やアプリケーションを利用しているのであれば、
証明書の信頼性について Microsoft の判断を信頼するのは、許容
できる範囲のリスクなのでは?
Re:問題点の説明が不十分 (スコア:2, 参考になる)
開始したとき、このいわゆる「オレオレ証明書」を用いて詳細な
個人情報を登録した上でしか使えないようにしていましたが、
その後クレームが付いたからか、オレオレ証明書のSSL使用をやめて
個人情報の収集もやめる変更をしましたね。
変更される前に集めた個人情報はどのように処理したのか不明ですが、
個人情報を入力するサーバが確かな組織の管理下にあるのか保証する
ことができないなら、個人情報の入力自体をやめてしまうというのも
一つの手段ではありますね。
Re:問題点の説明が不十分 (スコア:1)
/.なら不要じゃん？って書こうとしたけど、いろんな書き込み見てるとあってもいいかもしれませんな。
Re:問題点の説明が不十分 (スコア:2, おもしろおかしい)
# 記事はルートアレゲな人から認証を受けて発行されています。
Re:デタラメ言うな (スコア:1)
アプリを提供するときに、アップデートとかする場合を考えてルート証明機関としてアプリに公開鍵入れといて、SSLでパッチのハッシュ値のやり取りをしているみたいな話なんじゃ？
どこかの証明機関から認証貰っていたとしても、他の証明機関に乗り換えることもあるだろうし、証明機関が倒産することもある。
やっているかどうかは知らんが、不自然じゃない気がするけど。
それとも、マイクロソフトが初めではないって話か？
Re:デタラメ言うな (スコア:4, 参考になる)
どういうことなのかは、以下のLarry Osterman氏のblogにまとまっています。
- Why doesn't Mozilla (Firefox) like the Microsoft OCA web site? [msdn.com]
この仕様が、Microsoftの勝手な独自機能なのか、それとも他のブラウザも搭載すべき標準仕様と解釈するべきなのかについて、Bugzilla Bug 245609 で議論されています。Re:デタラメ言うな (スコア:2, 参考になる)
Apachi なりに付いてくるスクリプトで証明書を発行すると、
ブラウザでは、「鍵の発行者が署名をしてる。」といって、
承認するか、セッション毎に「署名者の正統性」の確認を求められます。（サーバ鍵）
しかし、openSSL なりを使って、ユーザが鍵を発行し、其の鍵に、「プライベート認証局」の管理者が署名をすると、
ブラウザでは、「署名をした認証局を信頼する」 と、最初に答えると、上記のような確認は最初の一回のみです。
つまり、ユーザ鍵の製作者と、鍵の署名者が違うモノは、「プライベート認証局」と言って良いと思ってます。
これは、サーバ側が正規の登録ユーザかどうかを見分ける目的のためには、上位認証局は必要ありません。
サーバ証明書も署名認証局から見れば、一ユーザに過ぎず、
サーバの正当性では無く、署名した認証局の信頼性を問われている訳ですから、
「オレオレ証明書」 つまり、「自己署名サーバ鍵」とは違うんじゃないですか？ と、言いたかった訳です。
それで、「サーバ鍵」の署名者である、「NTT西日本の認証局」は、正規の認証局ツリーに組み込む。
つまり、正規の上位認証局の署名があれば、問題は起きなかったね。 と、思った訳です。
hoihoi-p 得意淡然、失意泰然。
Re:んー疑問を一つ (スコア:2, 参考になる)
# 上場企業だと省略可です。
ちなみに、証明書が証明しているのは、そのサイトが確かに(例えば)「平成電○」という会社のサイトだということだけで、その「平成電○」自体が信用できるかどうかとは完全に別問題です。
Re:んー疑問を一つ (スコア:2, 参考になる)
＞金さえ払えば誰でも取れるって聞いたことがあるんですが。
上の議論でも出てくるCPSという用語がその疑問に関係しています。
「どのようにすれば証明書が発行してもらえるか」というような証明機関の運用規則は，CPS（Certification Practice Statement）という文書にまとめてあります。証明機関はCPSを公開することが各種の規格で義務付けられており，ブラウザにルート証明書が同梱されているような証明機関ならば必ず何らかの方法で閲覧できるようになっています。
Verisignはこちら↓
http://www.verisign.co.jp/repository/CPS/
Re:ISMS (スコア:2, すばらしい洞察)
まず、ISMSはセキュリティマネジメントの体系を確立できているかどうか、というのが認証基準であって、「いわゆる一般的なセキュリティ基準を満たしているかどうか」が認証基準ではありません。
リスク管理の観点から言えば、対策コストに見合うリターンが得られないと判断されるのであればリスクを放置するのもまたリスク管理です。そういった意味で、PKIをどうこうというのはISMSには直接的には関係ありません。
また、取得範囲についても、今回ISMSの認定を受けたのは同社のソリューション営業本部であって、全社的にISMS認定を受けたわけではありません。従ってソリューション営業本部でISMSを取得したからといってNTT西日本全社でセキュリティマネジメントが確立されているという意味にはなりません。
要するに、そもそもタレコミ文の「NTT西日本がISMSを取得」という表現が微妙だし、ISMS的には直接は問題ないものと判断されます (むしろ、事後対応でどう出てくるかという方が問題でしょうね）
･−− ･− ･･･ ･･･ −･−−