アカウント名:
パスワード:
を用意して、できるだけ決済権に近い人の目の前でテストすることができれば、警告が表示されたときに戸惑う様を見せることができます。
というか、たいてい決裁権者は初心者なので、まともなブラウザや IE でも安全な設定で使わせて、警告を見せることができれば「かっこ悪い」と感じると思います。「なんだこの邪魔くさい感じは」と思わせれば少し道が開けるんじゃないでしょうか。
「壊れた」
素人であるユーザーにとってはどういう経緯で証明書が発行されていようが、そんなことはどうでもいいわけですから、そこら辺が現場の腕の見せ所なんでしょう。
証明書の値段そのものよりも、期限切れの証明書を保守し続けるコストの方が気になります。
ひどいサイトだね。怖くて近寄れん。
CP/CPS のようなものは一応書いてあるものの、3行だけ。
・ルート証明書は、通信路の暗号化、サーバ証明書による IPA側のWEBサーバ(e-ipa.ipa.go.jp)の認証、クライアント証明書による申請者クライアントの認証を行なうために使用されます。 ・サーバ証明書とクライアント証明書は、IPAが電子的に申請、応募、応札等を受理する目的で使用されます。 ・IPAでは、ルート証明書の秘密鍵の管理については、十分注意を致します。 ルート証明書のダウンロードとインストール [ipa.go.jp]
安全な通信を行うための証明書についての詳しい説明 [mof.go.jp]の3.あたりに、フィンガープリントを確認したうえで、財務省が発行する証明書をブラウザに登録してください、などとありますが、、、。
#よくわかってなくて恥をさらすようでも ID
ググってみた。このへんかな。
[memo:3458] 総務省「電子申請・届出システム」のセキュリティ上の問題点 [ryukoku.ac.jp] セキュリティホールmemo 2002.3 総務省「電子申請・届出システム」は信頼できるか [srad.jp] wakatonoによる 2002年03月29日 15時38分の掲載 <電子政府>総務省の認証基盤に欠陥 個人情報盗用も [mainichi.co.jp] 毎日新聞ニュース速報 2002年10月31日 総務省:「電子政府に100%の安全はなく、やむを得ない」 [srad.jp] Oliverによる 2002年11月02日 2時25分の掲載 GPKIおよびLGPKIにおけるルート証明書配布方式の脆弱性と解決策 [ryukoku.ac.jp] セキュリティホールmemo 2002.11
毎日の記事が消えてるけど Internet Archive にあった。 http://www.mainichi.co.jp/digital/solution/archive/200211/08/2.html [archive.org]
電子政府や電子自治体の利用者は、パソコンに詳しいとは限らない。全国民が対象なのだ。片山さんのように、(繰り返してごめんなさい)パソコンモニターとタッチパネルの区別が難しい人々でも、安心して簡単に使えることこそ求められている。要は、片山さんが「これなら簡単」というようなシステムを作ればいいのである。 その点を頭に入れて、政府認証基盤(GPKI)について考えてほしい。総務省の担当者は「利用者の利便性を考えると、インターネットとブラウザーの利用は避けられない」と言う。全くその通りだ。だが、(繰り返してごめんなさい)片山さんのような方々にとって、ブラウザーにルート証明書を組み込み、なおかつフィンガープリントを確認することは容易だろうか。 そのうえで、「ブラウザーにルート証明書を安易に組み込んだら危険だ」ということを理解、徹底させ、なおかつ暗号化されていないサイトからダウンロードしたルート証明書が、万一改ざんされて被害が発生した場合の法的責任について、納得していただくことができるだろうか。 (snip) 総務省側は、フィンガープリントの確認サイトのためだけにでも、標準的な暗号化方式SSLを利用することについて、「民間認証機関が発行するサーバー証明書が必要で、認証の根底には政府認証基盤ではなく、民間認証機関を置くことになって問題」とコメントしている。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
証明書の取らせかた (スコア:2, 興味深い)
この手の隙をついた攻撃があまり無いから具体例として被害の例も挙げることが出来ないですし、イマイチ良い説得方法が見付かりません。
...みなさんどうやって説得してるんですかね?
Re:証明書の取らせかた (スコア:4, 参考になる)
Re:証明書の取らせかた (スコア:2, 参考になる)
VodaとかDoCoMoだと、ダイアログでいけちゃったとおもいます。
Re:証明書の取らせかた (スコア:2, 参考になる)
# auの携帯を持ってるひとは試してみよう。
# トップメニュー → 「4.ライフ」 → 「バンキング・マネー」 → 「都市銀行」 → 「三井住友銀行」
Re:証明書の取らせかた (スコア:2, 参考になる)
を用意して、できるだけ決済権に近い人の目の前でテストすることができれば、警告が表示されたときに戸惑う様を見せることができます。
というか、たいてい決裁権者は初心者なので、まともなブラウザや IE でも安全な設定で使わせて、警告を見せることができれば「かっこ悪い」と感じると思います。「なんだこの邪魔くさい感じは」と思わせれば少し道が開けるんじゃないでしょうか。
Re:証明書の取らせかた (スコア:0)
この方法以上に有効な説得方法は無いだろうかと常々考えてはいるのですが。
Re:証明書の取らせかた (スコア:0)
現に晒されてるわけだし。
Re:証明書の取らせかた (スコア:0)
やはりマジメに危険性を訴えていくしかないかと。
過去の被害がまとまっている資料があればよいのですけど。
Re:証明書の取らせかた (スコア:1)
本物サイト←→中継サイト←→被害者
のデモ環境を作って、一通り実際に操作させてから「ほら、それだと全部だだ漏れになってます」と見せるしかないのかなぁ。
Re:証明書の取らせかた (スコア:1)
あの手のダイアログって、なんだか知らないけど、
と思う人が多いみたいですね。そんなので呼び出された事が何度かあるんですが。
#違う話だけど、何かのアプリを入れてIEのホームページが変更されただけで、
#「IEが壊れてヘンなページがっ!」ってのもあった。
確かに警告なのかも知れないけど、もうちょっと柔らかな感じで見せた方が良いのかも知れません。
例えば萌え系で攻めるとか(ぇー)。
「なんとかインチキできんのか?」
Re:証明書の取らせかた (スコア:1, 興味深い)
Re:証明書の取らせかた (スコア:0)
偽サイトなんかアドレスバーを見ればわかるわけで。
偽サイト以前に、通信路上で盗聴されることが問題です。
Re:証明書の取らせかた (スコア:4, 参考になる)
他にもhostsファイルが改ざんされたとか、ブラウザのバグをやられたとか。
アドレスバーはあくまで目安で本当は何処にどのように繋がってるかなんて解らないんです。
その途中の経路も含めて保障してくれるのが正しく運用されたSSLなんですけど。
Re:証明書の取らせかた (スコア:0)
あなたのようなことを言っていると、こう言われちゃうわけよ。
だから「偽サイト以前に、通信路上で盗聴されることが問題です」と言ってるの。わかんない?
Re:証明書の取らせかた (スコア:0)
あなたのようなことを言っていると、こう言われちゃうわけよ。
Re:証明書の取らせかた (スコア:0)
>他にもhostsファイルが改ざんされたとか、ブラウザのバグをやられたとか。
>
>アドレスバーはあくまで目安で本当は何処にどのように繋がってるかなんて解らないんです。
>その途中の経路も含めて保障してくれるのが正しく運用されたSSLなんですけど。
そっかー、hostsファイルは改竄される危険があるけど、
ルート証明書は改竄される心配は無いんだね!
ブラウザのバグでアドレスバーが書き換えられることは
あるけど、SSLが書き換えられることは無いんだね!
SSLって凄いね!
Re:証明書の取らせかた (スコア:0)
鍵(ハッシュ)が合わなくなるんじゃないの?
Re:証明書の取らせかた (スコア:1)
つまり、hostsを書き換えるトロイを流布するファーミング詐欺犯は、同時にオリジナルルートCA(VeriSignとか名乗ることもできる)も追加インポートするようにトロイを作り、オリジナルルートCAで署名したサーバ証明書で、フィッシングサイトを運営するわけですから、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:証明書の取らせかた (スコア:0)
こんなんでいいのかね。
Re:証明書の取らせかた (スコア:1, 参考になる)
Re:証明書の取らせかた (スコア:0)
まさか君は Windows Update をしていないのかい?
そんな人は SSL 以前に、スパイウェア食いまくりだろうね。
Re:証明書の取らせかた (スコア:1, おもしろおかしい)
しかしサーバー側がアドレスバーを消してしまった。
どうしますか?
1.帰る
2.文句を言う
3.うろたえる
Re:証明書の取らせかた (スコア:1, 参考になる)
部門サーバー群の一部が落ちた事をアナウンスする時とかどれが見れてどれが見えないのかってのを何度も何度も聞かれますし。
# そのサーバーでは Web サーバー上げて無くても聞かれたり。
いや、まず盗聴が問題というのは確かですが。
Re:証明書の取らせかた (スコア:1)
DNSまで偽物捕まされますし、、、
uxi
Re:証明書の取らせかた (スコア:1)
んなの見ない奴が多いってことと、アドレスバーを隠蔽するタイプのもいたりするんだな、これが...
# アドレスバーの上に被さったのをずらせば解るっちゃわかるけど、「見る」だけではね。
Re:証明書の取らせかた (スコア:0)
貴方は即座に見破ってくれるわけですね
Re:証明書の取らせかた (スコア:1)
詳しい図解入りの説明書作ったって良いだろうし、解説しているサイトに誘導するのでも良いのでは?
口で言ってまくし立っても、それをイメージ出来ていない奴がぱっとイメージ出来る訳ないよ。
言われた方が上司を説得するにしても、資料が無いと説明し難いだろうし。
Re:証明書の取らせかた (スコア:2, 興味深い)
素人であるユーザーにとってはどういう経緯で証明書が発行されていようが、そんなことはどうでもいいわけですから、そこら辺が現場の腕の見せ所なんでしょう。
Re:上司の承認プロセスにおけるマーフィーズロウ (スコア:3, すばらしい洞察)
しかも、その階層図は2ヶ月後にはあてにならなくなる。
・上司の技術的バックボーンが異なり、畑違いの言葉で説明をつけたすため
伝言ゲームでのやりとりをすると、必ず意味合いが変わってしまう。
・技術説明ミーティングを開けば良く集まり、よく理解したような手ごたえがある。。
しかし、必ず後で倍のフォローが必要になる。
・技術的説明が必要な人間は必ず同じフロアにいない。
そういう人間が会議に出たときに限って機材が原因不明のトラブルに遭う。
・すべての承認を取り付けたと一息ついた所で
別部門に対して同じプロセスが必要だと知らされる。
(振り出しにもどる)
この条件に当てはまる数が多いほど、そのプロジェクトが
正月休み等のイベントを台無しにする可能性が高いです。
気をつけましょう。
素人の意見は・・・ (スコア:1)
ホントはどうでも良いどころか大事なことなのに、理解できないのが根本的な問題かも。
素人の反応を予測すると
・住所が西の人
「よくわかんないけどしっかりしてね。」
・住所が東の人
「ウチは東だから大丈夫なんでしょ?」
Youthの半分はバファリンでできています。
Re:証明書の取らせかた (スコア:0)
タダで取れるならともかく、結構な額がかかるものですから、結局予算の話の中でコストとリスクを評価されて、真っ先に削られる候補になるんです...。
Re:証明書の取らせかた (スコア:3, おもしろおかしい)
だから証明書の購入コストってのは全然大したこと無いと思います。
ただ、証明書の値段そのものよりも、期限切れの証明書を保守し続けるコストの方が気になります。
一つのプロジェクトで最初にかかるコストが数千や数万円かかるくらいはたいしたことがないと思います。
でも証明書の更新ってのは1年後か長くても数年後には確実に来るものです。
そしてその頃当時のメンバー(特に証明書のことをきちんと分かっている人)が居るかどうかは分かりませんし、更新時期にはプロジェクトに全く関係の無い人間しか居ないこともざらかと思います。
プロジェクト開始時には何の問題も無かったのに、分かる人が居ないかも知れない未来に託して、期限切れが放置されて客からクレーム(第3者から騒がれたとか、突然ダイアログが出るようになったとか)を受けて、自分たちのプロジェクトに泥が付くというのはやりきれないでしょう。
きちんとした運用マニュアルを作ってその通り運用すれば良いと言う意見も当然ですが、そうすることが出来ないケースも多いでしょうし。
そこで「暗号化はされますがサイトの身分証明は出来ないので第3者に誘導された場合の改竄や盗聴の防止にはなりません。それにダイアログも当然出るのでユーザにOKボタンを押して貰うことになります。」
ということを顧客に説明して一度妥協してオレオレ証明書でスタートしてさえしまえば、
後に証明書の期限切れになったとしても、ダイアログが出たらOKを押して進めるというのに慣れたユーザはそのダイアログに期限切れの注意マークが増えていることに気づくことも無くクレームはおきにくい。
という保守コストも削れる駄目駄目な楽チン解の方が良いということも多いでしょう。
技術者ってのは当面のコストよりも将来の保守を嫌う傾向があるようですし…。
なので証明書のコストを議論する際は、証明書1枚の値段よりも証明書の更新の簡単さ(出来れば人が何もしなくても自動更新できると嬉しい)が必要だと思ってます。
Re:証明書の取らせかた (スコア:0)
ひどいサイトだね。怖くて近寄れん。
Re:証明書の取らせかた (スコア:0)
例えば IPA セキュリティセンターの脆弱性関連情報の届出 [ipa.go.jp]が活用されると状況も変わってくるんじゃないかな。
# IPA から修正依頼が何度か来たので AC
Re:証明書の取らせかた (スコア:1)
CP/CPS のようなものは一応書いてあるものの、3行だけ。
Re:証明書の取らせかた (スコア:0)
Re:証明書の取らせかた (スコア:2, 参考になる)
それだけではなく、運用の厳密さは私の関わっていた金融関連(金融機関のシステムは金融庁のガイドラインでかなり細かく運用方法が縛られている)のシステムとも比べものになりません。
私はとても同じとはいえませんね。
Re:証明書の取らせかた (スコア:1)
安全な通信を行うための証明書についての詳しい説明 [mof.go.jp]の3.あたりに、フィンガープリントを確認したうえで、財務省が発行する証明書をブラウザに登録してください、などとありますが、、、。
#よくわかってなくて恥をさらすようでも ID
Re:証明書の取らせかた (スコア:1)
ところで、これの確認方法どのあたりが危険なのでしょうか?
比較するフィンガープリントを暗号化されていない(改ざん対策されていない)ページに載せていること?
Re:証明書の取らせかた (スコア:1, 参考になる)
>比較するフィンガープリントを暗号化されていない
>(改ざん対策されていない)ページに載せていること?
ググってみた。このへんかな。
[memo:3458] 総務省「電子申請・届出システム」のセキュリティ上の問題点 [ryukoku.ac.jp] セキュリティホールmemo 2002.3
総務省「電子申請・届出システム」は信頼できるか [srad.jp] wakatonoによる 2002年03月29日 15時38分の掲載
<電子政府>総務省の認証基盤に欠陥 個人情報盗用も [mainichi.co.jp] 毎日新聞ニュース速報 2002年10月31日
総務省:「電子政府に100%の安全はなく、やむを得ない」 [srad.jp] Oliverによる 2002年11月02日 2時25分の掲載
GPKIおよびLGPKIにおけるルート証明書配布方式の脆弱性と解決策 [ryukoku.ac.jp] セキュリティホールmemo 2002.11
毎日の記事が消えてるけど Internet Archive にあった。
うーん、なんだかなあ。http://www.mainichi.co.jp/digital/solution/archive/200211/08/2.html [archive.org]
Re:証明書の取らせかた (スコア:1)
万が一 (攻撃者にとって万が一、ですよ) ユーザが正しいサイトにつなげて
しまったとしても、警告も出ないのでは?
ルート証明書の一覧を確認すれば載ってますが、普通は気づかないでしょう。
Re:証明書の取らせかた (スコア:0)
よくそういう言い訳を聞くけど、それは全体のコストの何パーセントなの?
1パーセント以下でしょ、普通。
Re:証明書の取らせかた (スコア:0)
Re:証明書の取らせかた (スコア:0)
って、「んなこた滅多に起こらんだろう」とか言われて、「想定利用者数×500円×限りなく0に近い数字」で計算されたら、やっぱり削減対象か。うーん……。
Re:証明書の取らせかた (スコア:0)
「ほら、対策を取ってなかったから」
Re:証明書の取らせかた (スコア:1)
×攻撃を受けた
◯損害を受けた
だと思うんだよね、実際は....で、その損害は誰がかぶるで、もめちゃったりして、損害をさらに増やすというわけでして...
Re:証明書の取らせかた (スコア:0)
はっ?実例なら幾らでもあるだろう。
フィッシング詐欺と呼ばれているものが、そうだよ。
そのサーバーが本物か否かを判断する方法(SSL)を
運営側が提供していない&ユーザーに周知させていない
のが根本原因なんだから。
こないだあった、偽YahooNewsもそうだな。