アカウント名:
パスワード:
VeriSign が潰れちゃったときにどうするかとか 10～20年くらいのスパンで考えると、問題があったのかも。
VeriSignのルートCAだって開始当初は信頼性なんて無かったのだから、
そういう話ではないですね。VeriSignが潰れたら Baltimore Technologies に切り替えればいいですね。総務省CAの証明書を配布するためのサーバーのサーバー証明書の話をしているんであって
ウェブブラウザに最初から入ってましたが？
んー、最初から入っているものの信頼性をどう感じるかは個人の自由ってことにしておいてください。
ブラウザベンダーには、だめなCAがいたら、ブラウザのインストーラから外して欲しいわけですが、そのような市場原理は正しく働くんでしょうかね…。
普通にVerisignとかで証明書取った方が面倒なくて良いと思うのですが 自身をルート証明局にしなきゃいけない理由ってあるのかなぁ？
元記事の「証明書のダウンロードがSSLでない」という話は、ピント外れですね。 証明書というのは、その証明書のフィンガープリントと、公表されているフィンガープリントが一致する事を確認すれば正当性が認証できるのだから、SSLにする必然性は無い。 もちろんSSLでダウンロードできるようにすれば、フィンガープリントの確認までしなくても多分大丈夫だろうなと何となく安心できるというメリットはあるかもしれないけど、「何が何でもSSLじゃないのはダメだ」というのは言い過ぎかつ誤り。 たとえSSLなサイトにその「証明書」があったとしても、そのサイト自体が総務省が「証明書」を置いたサイトであるという事は証明できない SSLが証明できるのは、そのコネクションが該当URLのサイトから送られてきたものである事を証明できるだけで、他所のhttpsなサイトにその「証明書」（の偽物）を置かれてもそれが「偽物」か「本物」かはSSLでは証明不可能。 たとえば、httpな総務省のDNSをスプーフィングして「ダウンロードはこちらhttps://fakedomain.com/から行ってください。URLがhttps://fakedomain.com/である事を確認してください」とかいうページに挿し換えられてしまうと、偽物の証明書を本物と思ってダウンロードさせられてしまう事になります。 じゃあ、そのダウンロードの説明ページを更にSSLにして...と遡って行けば、結局は全部のWebはSSLにしなきゃいけないという所まで行き着いてしまいます。 そんな事をするぐらいなら、証明書のダウンロードがSSLかどうかという事を思案するよりフィンガープリントと照合した方が余程か簡単だし早いし無駄な税金をVerisignのために使う必要もありません。 そういう意味で、この「証明書がSSLなページに無いのは脆弱だ」という指摘は的外れですね。 その上、「SSLなサイトにあれば大丈夫」という誤った認識を与える可能性のあるという意味で、脆弱性を引き起こす可能性のある主張です。
フィンガープリントが同じhttpのサイトにあるのが問題というのは正しい認識でしょう。 memoMLでフォローアップされてましたが、これは別経路で官報で告示するとか、そういうのが必要でしょう。
たとえSSLなサイトにその「証明書」があったとしても、そのサイト自体が総務省が「証明書」を置いたサイトであるという事は証明できない SSLが証明できるのは、そのコネクションが該当URLのサイトから送られてきたものである事を証明できるだけで、他所のhttpsなサイトにその「証明書」（の偽物）を置かれてもそれが「偽物」か「本物」かはSSLでは証明不可能。
たとえば、httpな総務省のDNSをスプーフィングして「ダウンロードはこちらhttps://fakedomain.com/から行ってください。URLがhttps://fakedomain.com/である事を確認してください」とかいうページに挿し換えられてしまうと、偽物の証明書を本物と思ってダウンロードさせられてしまう事になります。
じゃあ、そのダウンロードの説明ページを更にSSLにして...と遡って行けば、結局は全部のWebはSSLにしなきゃいけないという所まで行き着いてしまいます。
SSLのサーバー証明書というものはですね、その証明書の所有者が誰であるのか、ということをですね、法人であればその登記簿謄本等に記載されている組織名と照合してですね、その組織名を表示しているところに意味があるんです。
その場合は、「https://fakedomain.com/」のサーバー証明書の所有者を確認しなかった利用者の自己責任ということになりますね。
いえいえ、ダウンロードの説明ページが、https://….soumu.go.jp/ となっていて、サーバ証明書の所有者に「日本国総務省」と書かれていれば、よいですね。
そのサーバにはそのサーバの持ち主が望めばそのサーバを設置した組織と関係無いコンテンツを置く事ができ、そのコンテンツが誰の物であるかは証明できません。
そのサーバにあるコンテンツであるルート証明書が確かに日本国総務省のものであるかどうかという証明は、SSLのサーバ証明書ではできません。
ですから、SSLのサーバ証明書では悪意のある者によって管理されている、あるいはクラックされたサイトに「日本国総務省のものである」と主張する「(偽物の)ルート証明書」が置かれる事を抑止する事はできません。
自己責任で話が済むのであれば、httpなサイトに置いたルート証明書のフィンガープリントを確認しなかった利用者の自己責任で済むじゃないですか。 それで済まないから「SSLでないのはマズい」って言ってるのではないのですか？
そのhttpsなサイトのURLはどうやって知るのですか？ http://...soumu.go.jp/なサイトからのリンクであれば、http://...soumu.go.jp/のコンテンツを摩り替える事によって、別のダウンロードページへ導く事は可能ですね。
何も私は「今の総務省のやり方で全く問題無い」って言ってる訳ではありません。 SSLを使えば「正しい」証明書を「正しいもの」と確認する事はできますが、誤誘導された先で掴まされた偽物の証明書が偽物であるという事を認識させるためには何の役にも立たない。 「正しい」証明書が「正しいもの」と確認するためにはフィンガープリントという手段があり、その上SSLまでしなきゃいけないという必然性は無いのだから、「SSLじゃないから脆弱だ」と言う程の事も無いのでは？ という事です。 この総務省の「脆弱性」の一番大きなものは、「フィンガープリントを同一httpサーバで提示している事」であって、「SSLでない」というのはそれ程大きな問題ではない。 それなら、そういうノイズによって「SSLじゃないから危ないんだ」というミスリードを引き起こす可能性のあるような問題の提起の仕方はマズいんじゃないかというのが私の考えです。
本物のルート証明書をSSLなサーバに置いたとしても、そこへ至る経路がhttpであれば、別のサイトへ誘導される可能性がある。
ダウンロードする画面で、 あんたは、今見ている画面のURLを確認しないのか？ 確認するだろ。 https://….soumu.go.jp/ のサイトであることを確認するだろ？ 証明書の所有者も確認するだろ？
確認しないのならそれは自己責任です。
「正しい」証明書が「正しいもの」と確認するためにはフィンガープリントという手段があり、その上SSLまでしなきゃいけないという必然性は無いのだから、「SSLじゃないから脆弱だ」と言う程の事も無いのでは？
だから何回も何回も同じこと言ってんじゃん。どうしても理解したくないのか？
「その上SSLまで…」とかではなく、 SSLで上記の通り正しくダウンロードしたならフィンガープリントの照合は不要になるのです。
jbeefさんが前提条件として「その上SSLまで」 ということは関係ないだろうということで > > 「その上SSLまで…」とかではなく、 SSLで上記の通り正しくダウンロードしたなら > > フィンガープリントの照合は不要になるのです。 と書かれたのだと思いますが、違いますか？
ご指摘感謝＞AC氏
どうも言葉をいくら重ねても言ってる事がわからないようなので、
それでは4.も改竄されないように4.もSSLにしましょう。
でも3.のuseconsent_ie.htmlは相変わらずhttpですから改竄されて...という繰り返しになって、
そう、そこで、ユーザは、4.のページが https://….soumu.go.jp/… になってて、そこのサーバー証明書が総務省のものになってることを確認するのが当然なの、と、何回も何回もネー、言ってるでしょ？
でも3.のuseconsent_ie.htmlは相変わらずhttpですから改竄されて...という繰り返しになって、 もしかして、あんた、今見てるページのURLを見ない人か？そりゃあ論外だよ。やられ放題だな、電子政府に限らず。
そう、そこで、ユーザは、4.のページが https://….soumu.go.jp/… になってて、そこのサーバー証明書が総務省のものになってることを確認するのが当然なの、と、何回も 何回もネー、言ってるでしょ？ だから、正しいページが正しくダウンロードされたなら、そうやってそれが正しいという事を知ることはできるよ。それは全然否定してないでしょ？ 問題はそうじゃなくて、その正しいページへ至る過程にhttpなページがあれば、
そう、そこで、ユーザは、4.のページが https://….soumu.go.jp/… になってて、そこのサーバー証明書が総務省のものになってることを確認するのが当然なの、と、何回も 何回もネー、言ってるでしょ？
4.のページがダウンロードされた後に、URLと証明書を確認すれば4.のページは正しくダウンロードされたってこと。それを確認してから、そこからリンクされているルート証明書を安全にダウンロードするわけ。 最後のルート証明書のダウンロードを実行する直前で、今見ているページがどこなのか、SSLになっているのか、証明書は誰のものなのかを確認するのが、ユーザの当然のとるべき行動なのだ、って言ってるわけ。（あんたはURL見ないんだろうけどな。）
DNSスプーフィングされるという事は、ちゃんとhttp://...soumu.go.jp/というURLに見えるページが改ざんされちゃうという意味ですよ。わかってる？
あらかじめhttps://...soumu.go.jp/というURLにルート証明書が存在する事がわかっていればルート証明書をダウンロードする所でhttpsじゃないからおかしいとわかるかもしれないけど、
だからさ、そのフィンガープリントは今どこに置いてあるの？ http:// のサイトに置いてあって、それと比べろって、総務省は言っているわけよ。
確かに、フィンガープリントを正しく照合するならば、証明書が偽物でないか を確認することができる。 ところが、「総務省認証局について」の部分のリンク先 http://www.shinsei.soumu.go.jp/ninshoukyoku.html#finger には、 (snip)
元記事が紹介している「投稿した記事」にまさにそうだって書いてあるじゃん？読まずにカキコ？
元記事の「証明書のダウンロードがSSLでない」という話は、ピント外れですね。 証明書というのは、その証明書のフィンガープリントと、公表されているフィンガープリントが一致する事を確認すれば正当性が認証できるのだから、SSLにする必然性は無い。
確かに、フィンガープリントを正しく照合するならば、証明書が偽物でないかを確認することができる。
…云々、fingerprintについてもきちんと触れています。
この問題に限らないけど、他人に対して指摘するのであれば、あれもこれもと言うよりは「本当に必要な事をピンポイントで提示する」というのが受け入れられる可能性の高い手法です。 そういう意味ではこのSSL云々っていうのはノイズであって、相手に対して「あぁ煩いやつだなぁ」と思われるだけでしょう。 そもそもついでの話を最初に持ってきて、本来必要な「異経路」で「フィンガープリントを正しく伝える必要性」がノイズと同列に扱われているのは「本当にこの人わかって言ってるの？」と思われかねません。
売名が目的ではなく、真に「良い環境」を求めるのであれば、言いたい事を言いたいように言うだけでなく、「どう指摘すれば受け入れられるか」という事も考える必要があるのではないでしょうか？
「元記事の」以降は参考にならない(-0.5)
SSL に頼らず SSL と同等の安全性がある方法を教えてください。自分でフィンガープリント受け取りに出向く？
それと山田君、座ぶとん持っていきなさい２枚は多すぎる。
memoMLでフォローアップされてましたが、これは別経路で官報で告示するとか、そういうのが必要でしょう。
で、ブリッジ認証局を介す以上、民間認証局からサーバ証明書を貰うわけには行かないだろうというのが一点。
しかし、だからといって、Webサーバーのサーバー証明書についてもそうだ、というのは必ずしも正しくないでしょう。Webと電子署名法は無関係でしょうから。
サーバー証明書は、特定認証業務の認定を受けていないところから取得しても問題ないのではないでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
理由はあるの？ (スコア:2, 参考になる)
普通にVerisignとかで証明書取った方が面倒なくて良いと思うのですが
自身をルート証明局にしなきゃいけない理由ってあるのかなぁ？
ＥＣサイトの開発時やテスト時には良くやりますけど正式オープン前に
大概どこぞのＣＡで証明書取りますよね。
それが普通だと思っているのですが・・・お役所的には普通でない？
重蔵。
Re:理由はあるの？ (スコア:2, 興味深い)
公開鍵暗号手順(RSA)自身に脆弱性が見つかったときの対処とか
VeriSign が潰れちゃったときにどうするかとか
10～20年くらいのスパンで考えると、問題があったのかも。
VeriSignのルートCAだって開始当初は信頼性なんて無かったのだから、総務省が自己署名の証明書を使うこと自体に問題は無いでしょう。
問題は、ルートCAの公開鍵の正当性を証明する方法に問題があったわけで、
「フィンガープリントを官報に載せる」
っていう方法でも良かったんじゃないかと思うんですけどね…
「官報なんて紙媒体だからいくらでも偽造が…」
って言いだしたら紙幣も使えないよね(笑
総務省CAをVeriSignに置き換えよという話ではないよ (スコア:2)
Re:総務省CAをVeriSignに置き換えよという話ではない (スコア:1)
ああ、すみません。
私は、「自己署名でやればいいのに」って思ってたので、前出のようなコメントになってました。
ちょっと話がとびすぎてましたね。
んー、最初から入っているものの信頼性をどう感じるかは個人の自由ってことにしておいてください。
Re:総務省CAをVeriSignに置き換えよという話では… (スコア:2)
ブラウザベンダーには、だめなCAがいたら、ブラウザのインストーラから外して欲しいわけですが、そのような市場原理は正しく働くんでしょうかね…。
Re:総務省CAをVeriSignに置き換えよという話では… (スコア:0)
ルート認証局の公開鍵は、MS社からダウンロードして、
その時に、電話でフィンガープリントを確認済みのMS社の
公開鍵で確認すればいいんじゃないか？
別にホログラムが入ったきれいなCDなら必要ないかな
Re:理由はあるの？ (スコア:2, 参考になる)
まぁ、その気持ちもわからないでもないし、日本国よりも民間企業の方が信頼できるというのもアレゲな気はしますね。
本来であれば、ICANNなりの国際的に権威を持つ機関がルート証明局を運用すべきなのかもしれません。（もちろん実務は民間企業に委託しても良いのですが、証明はその機関が行う）
元記事の「証明書のダウンロードがSSLでない」という話は、ピント外れですね。
証明書というのは、その証明書のフィンガープリントと、公表されているフィンガープリントが一致する事を確認すれば正当性が認証できるのだから、SSLにする必然性は無い。
もちろんSSLでダウンロードできるようにすれば、フィンガープリントの確認までしなくても多分大丈夫だろうなと何となく安心できるというメリットはあるかもしれないけど、「何が何でもSSLじゃないのはダメだ」というのは言い過ぎかつ誤り。
たとえSSLなサイトにその「証明書」があったとしても、そのサイト自体が総務省が「証明書」を置いたサイトであるという事は証明できない
SSLが証明できるのは、そのコネクションが該当URLのサイトから送られてきたものである事を証明できるだけで、他所のhttpsなサイトにその「証明書」（の偽物）を置かれてもそれが「偽物」か「本物」かはSSLでは証明不可能。
たとえば、httpな総務省のDNSをスプーフィングして「ダウンロードはこちらhttps://fakedomain.com/から行ってください。URLがhttps://fakedomain.com/である事を確認してください」とかいうページに挿し換えられてしまうと、偽物の証明書を本物と思ってダウンロードさせられてしまう事になります。
じゃあ、そのダウンロードの説明ページを更にSSLにして...と遡って行けば、結局は全部のWebはSSLにしなきゃいけないという所まで行き着いてしまいます。
そんな事をするぐらいなら、証明書のダウンロードがSSLかどうかという事を思案するよりフィンガープリントと照合した方が余程か簡単だし早いし無駄な税金をVerisignのために使う必要もありません。
そういう意味で、この「証明書がSSLなページに無いのは脆弱だ」という指摘は的外れですね。
その上、「SSLなサイトにあれば大丈夫」という誤った認識を与える可能性のあるという意味で、脆弱性を引き起こす可能性のある主張です。
フィンガープリントが同じhttpのサイトにあるのが問題というのは正しい認識でしょう。
memoMLでフォローアップされてましたが、これは別経路で官報で告示するとか、そういうのが必要でしょう。
またここにもSSLを理解していない輩が…（＠鈴木証人 (スコア:2)
Re:またここにもSSLを理解していない輩が… (スコア:1)
しかし、そのサーバにはそのサーバの持ち主が望めばそのサーバを設置した組織と関係無いコンテンツを置く事ができ、そのコンテンツが誰の物であるかは証明できません。あくまでもそのサーバを設置した組織が「発信」した情報だと証明できるだけです。
そのサーバにあるコンテンツであるルート証明書が確かに日本国総務省のものであるかどうかという証明は、SSLのサーバ証明書ではできません。
ですから、SSLのサーバ証明書では悪意のある者によって管理されている、あるいはクラックされたサイトに「日本国総務省のものである」と主張する「(偽物の)ルート証明書」が置かれる事を抑止する事はできません。 自己責任で話が済むのであれば、httpなサイトに置いたルート証明書のフィンガープリントを確認しなかった利用者の自己責任で済むじゃないですか。
それで済まないから「SSLでないのはマズい」って言ってるのではないのですか？ そのhttpsなサイトのURLはどうやって知るのですか？
http://...soumu.go.jp/なサイトからのリンクであれば、http://...soumu.go.jp/のコンテンツを摩り替える事によって、別のダウンロードページへ導く事は可能ですね。
それとも、官報で告示するなり、TVCMでもする？
そんな事をするぐらいなら、同じ官報やTVCMでフィンガープリントを周知した方が安上がりだとは思いませんか？
Re:またここにもSSLを理解していない輩が… (スコア:2)
Re:またここにもSSLを理解していない輩が… (スコア:1)
- 本物のルート証明書をSSLなサーバに置いたとしても、そこへ至る経路がhttpであれば、別のサイトへ誘導される可能性がある。
- フィンガープリントをhttpな同一サイトに置くのは問題。
という事です。何も私は「今の総務省のやり方で全く問題無い」って言ってる訳ではありません。
SSLを使えば「正しい」証明書を「正しいもの」と確認する事はできますが、誤誘導された先で掴まされた偽物の証明書が偽物であるという事を認識させるためには何の役にも立たない。
「正しい」証明書が「正しいもの」と確認するためにはフィンガープリントという手段があり、その上SSLまでしなきゃいけないという必然性は無いのだから、「SSLじゃないから脆弱だ」と言う程の事も無いのでは？
という事です。
この総務省の「脆弱性」の一番大きなものは、「フィンガープリントを同一httpサーバで提示している事」であって、「SSLでない」というのはそれ程大きな問題ではない。
それなら、そういうノイズによって「SSLじゃないから危ないんだ」というミスリードを引き起こす可能性のあるような問題の提起の仕方はマズいんじゃないかというのが私の考えです。
Re:またここにもSSLを理解していない輩が… (スコア:2)
ダウンロードする画面で、 あんたは、今見ている画面のURLを確認しないのか？
確認するだろ。
https://….soumu.go.jp/ のサイトであることを確認するだろ？
証明書の所有者も確認するだろ？
確認しないのならそれは自己責任です。
「その上SSLまで…」とかではなく、 SSLで上記の通り正しくダウンロードしたならフィンガープリントの照合は不要になるのです。Re:またここにもSSLを理解していない輩が… (スコア:1)
どうも言葉をいくら重ねても言ってる事がわからないようなので、 具体的な例をあげてみます。
現在の総務省のページはIEの場合だと
- 総務省：電子申請・届出システム(http://www.shinsei.soumu.go.jp/)
- 電子申請・届出システムを初めてご利用される方へ(http://www.shinsei.soumu.go.jp/first.html)
- 使用許諾(http://www.shinsei.soumu.go.jp/useconsent_ie.html)
- 安全な通信を行うための証明書の入手と設定(http://www.shinsei.soumu.go.jp/first_ie.html)
- ルート証明書(http://www.shinsei.soumu.go.jp/download/soumuca.cer)
と辿る事になります。ここで、5.のルート証明書が通信経路の改竄やDNSスプーフィングによって差し替えられてしまう可能性があるのでSSLを使うべきであって、SSLを使えば5.のルート証明書が正しいものだと確認できるというのが趣旨ですね？
それでは5.のルート証明書をSSLにしましょう。
でも4.のfirst_ie.htmlは相変わらずhttpですから、同様に改竄されてhttps://www.shinsei.soumu.go.jp/download/soumuca.cerの代わりにhttp://www.shinsei.soumu.go.jp/download/soumuca.cerのリンクに置き換えられてしまうかもしれません。
そうなればいくら本物のルート証明書がSSLであっても偽物のhttp://www.shinsei.soumu.go.jp/download/soumuca.cerファイルをダウンロードさせる事ができます。
それでは4.も改竄されないように4.もSSLにしましょう。
でも3.のuseconsent_ie.htmlは相変わらずhttpですから改竄されて...という繰り返しになって、結局 https://www.shinsei.soumu.go.jp/download/soumuca.cer に至る可能性のある全てのページがSSLでなくてはいけないという事になってしまいますね？
もちろんそうしても良いのですが、そんな事をするぐらいならSSLに頼らなくても済むように、フィンガープリントの提供方法を見直せば良いのではないですか？ いつの間に「SSLにしたら手間が省ける」という話になったんですか？
私は一貫して「SSLでないと脆弱だ」という主張に対して「SSLにしたからと言って脆弱でないとは言えない」という話をしてるのですが。
Re:またここにもSSLを理解していない輩が… (スコア:0)
この部分にだけ反応して申し訳ありませんが、
そういうことではなくて、seldonさんが書かれた
> > > その上SSLまでしなきゃいけないという必然性は無いのだから、
> > > 「SSLじゃないから脆弱だ」と言う程の事も無いのでは？
にたいして、jbeefさんが前提条件として「その上SSLまで
Re:またここにもSSLを理解していない輩が… (スコア:1)
私が「その上...」と書いたのは、フィンガープリントという証明書の正当性を確認する手段があるのに、その上に「SSLにもしないといけない」「そうしていないのは脆弱である」という主張には必然性は無いという意味です。
手順としてフィンガープリントを確認してその上SSLのサーバ証明書も確認するという意味ではありません。
（が、私的にはいくら正当そうなURLで正当そうなサーバ証明書があったとしても、ルート証明書というセキュリティ上重要なものはフィンガープリントも検証すべきだとは思います。あくまでも、この件はここでは触れていないという意味です）
ご指摘感謝＞AC氏
Re:またここにもSSLを理解していない輩が… (スコア:0)
変にプライドを守って水掛け論(=フレーム)にするのは止めましょう。
見苦しいやりとりになっています ＞ seldon どの
Re:またここにもSSLを理解していない輩が… (スコア:2)
Re:またここにもSSLを理解していない輩が… (スコア:1)
問題はそうじゃなくて、その正しいページへ至る過程にhttpなページがあれば、その正しいページじゃなくて改ざんされたページに誘導されちゃう可能性があるという事を言ってるんだが... DNSスプーフィングされるという事は、ちゃんとhttp://...soumu.go.jp/というURLに見えるページが改ざんされちゃうという意味ですよ。わかってる？
あらかじめhttps://...soumu.go.jp/というURLにルート証明書が存在する事がわかっていればルート証明書をダウンロードする所でhttpsじゃないからおかしいとわかるかもしれないけど、そんな前提知識は無いでしょ。実際httpにある訳だし、元々ルート証明書はフィンガープリントで真正性を確認るものであって、SSLで確認するなんていう常識は存在しないんだから。
だったら、いくら本物をSSLで保護しても、そこまでにhttpなページがある限り、DNSスプーフィングで他の改ざんされたルート証明書に誘導されてしまう可能性は残るでしょ。
これだけ書いても理解できないんだったらあなたに説明するのは放棄する。
Re:またここにもSSLを理解していない輩が… (スコア:2)
4.のページがダウンロードされた後に、URLと証明書を確認すれば4.のページは正しくダウンロードされたってこと。それを確認してから、そこからリンクされているルート証明書を安全にダウンロードするわけ。 最後のルート証明書のダウンロードを実行する直前で、今見ているページがどこなのか、SSLになっているのか、証明書は誰のものなのかを確認するのが、ユーザの当然のとるべき行動なのだ、って言ってるわけ。（あんたはURL見ないんだろうけどな。）
だれが「http://」のページを確認しろなんて言った？ 「https://...soumu.go.jp/」のページを確認しろと言ってんだよ。わざと「s」を削ったのか？いいかげんにしろ。 だーかーらー、どうなっているかを知っていようがいまいが、とにかく、 ダウンロード直前の画面で、https://….soumu.go.jp のページで証明書を確認して、それからダウンロードするってのがユーザの責任だ（もしそこで、画面が http:// ならそのサイトは安全でないので使わないようにする）って、最初から言ってるだろ。fingerprint (スコア:1)
証明書自体とその fingerprint とが同じサーバに置かれていたらほとんど意味がないのは言うまでもありませんが。
鵜呑みにしてみる？
Re:fingerprint (スコア:0)
Re:fingerprint (スコア:1)
鵜呑みにしてみる？
Re:理由はあるの？ (スコア:1)
Re:理由はあるの？ (スコア:1)
このフィンガープリントという仕組みは「異経路で2つの情報を提供し、それらが一致する事で認証を行う」というのがミソであって、SSLかそうでないかなんて言うのは2の次です。（もちろんSSLの方が好ましいと言えるけど、「異経路」で「フィンガープリントが正しく伝えられる」という事の重要さに対して「証明書がSSLで伝えられる」という事の重要性はうんと低い）
この問題に限らないけど、他人に対して指摘するのであれば、あれもこれもと言うよりは「本当に必要な事をピンポイントで提示する」というのが受け入れられる可能性の高い手法です。
そういう意味ではこのSSL云々っていうのはノイズであって、相手に対して「あぁ煩いやつだなぁ」と思われるだけでしょう。
そもそもついでの話を最初に持ってきて、本来必要な「異経路」で「フィンガープリントを正しく伝える必要性」がノイズと同列に扱われているのは「本当にこの人わかって言ってるの？」と思われかねません。
売名が目的ではなく、真に「良い環境」を求めるのであれば、言いたい事を言いたいように言うだけでなく、「どう指摘すれば受け入れられるか」という事も考える必要があるのではないでしょうか？
Re:理由はあるの？ (スコア:0)
「元記事の」以降は参考にならない(-0.5)
SSL に頼らず SSL と同等の安全性がある方法を教えてください。自分でフィンガープリント受け取りに出向く？
ジジネコ？ (スコア:0)
ここまでは正解。この省庁、以前もそんなワガママ言ったあげく、使えないシステム作らせてた気が。。。学習してないな。
しかしながら、
> 元記事の
以降は、ハァ(ﾟДﾟ)ですな
# 個人的にseldon氏をスラドのジジネコ [javacats.com]に認定。。。
なにげにCA証明書とサーバ証明書の区別がついとらんのでは？
ブラウザにプレインストールされてないCAの公開鍵を使ってサーバ証明書が確認できても、そもそもそのCAの公開鍵がMPTによって発行されたもんかわからんよな？
だから、本来なら、そのCA証明書のFinger Pr
Re:ジジネコ？ (スコア:1)
フィンガープリントの扱いに問題があるという事は と書いている。
これは元記事の高木氏の指摘含め、別に異論は無いからたくさん書いてないだけ。 勝手に持って行きなよ。もう50枚もあるからいらん。
Re:ジジネコ？ (スコア:2)
Re:理由はあるの？ (スコア:1)
Re:理由はあるの？ (スコア:0)
それだったらそれを配るサーバーを別立てして、そのサーバーの証明書をVeriSignなりから買えばいいだろうに…、と思ってみるテスト。
Re:理由はあるの？ (スコア:1)
そして、構想 [gpki.go.jp]では、ブリッジ認証局を経由した相互認証をするということになっています。 確か、アメリカのFederal GPKI [cio.gov]でも、同様のスキームだったかと。アメリカと一緒だからどうなの？っていうのはありますが(^^;;
で、ブリッジ認証局を介す以上、民間認証局からサーバ証明書を貰うわけには行かないだろうというのが一点。
次に、民間認証局がブリッジ認証局と相互認証するためには、 電子署名法 [meti.go.jp]でいうところの、特定認証業務の認定を受ける必要があるということが二点。
その辺が理由だと思いますが。
written by こうふう
Re:理由はあるの？ (スコア:2)
しかし、だからといって、Webサーバーのサーバー証明書についてもそうだ、というのは必ずしも正しくないでしょう。Webと電子署名法は無関係でしょうから。
サーバー証明書は、特定認証業務の認定を受けていないところから取得しても問題ないのではないでしょうか。
Re:理由はあるの？ (スコア:0)
単に実験用の証明書を正式なものにするのを忘れているのに...