Comodo CAがサーバ証明書を関係のない第三者に発行、大問題に 81
くれといったらもらえちゃった、 部門より
あるAnonymous Coward 曰く、
本家のストーリにもなっているが、認証局として知られる「Comodo」のアウトソース先の証明書販売業者が、mozilla.com用のサーバ証明書を関係のない第三者に発行してしまう事件が発生したようだ（eWeekの記事「SSL Certificate Vendor Sells Mozilla.com Cert to Some Guy」、mozilla.dev.tech.cryptoグループに掲載されている事件の経緯）。
これをやらかしたのは「Certstar」というComodoの再販業者のようだ。StartComのEddy Nigg氏がこの再販業者に対してmozilla.com用のサーバ証明書の取得を試みたところ、何の本人確認手続きもなしに証明書が発行され手に入ってしまったのだそうだ。mozilla.dev.tech.cryptoでは、Comodoの人が出てきて、この再販業者からの発行を停止して調査中だと説明している。これに対し、再販業者をちゃんと管理できていないComodo自体が信用ならないとの主張が出てきて、MozillaはComodoを切るべきだという議論になっている。
タレコミ人は途中までしか読んでないが、その後「本当に切ったら多くのサイトが動かなくなって大変なことになる」といった議論が続いているようだ。結末はどうなったのだろうか。
また、あるAnonymous Coward 曰く、
MITM（中間者）攻撃は、以前Bugzillaに報告されていたケースなどのように、不明な発行者からの信頼できない証明書が使われることが多かった。しかし信頼されたSSL証明書を使ったMITM攻撃が本家/.にて紹介されている。
詳細は本家タレコミ人のブログで説明されているが、本家タレコミ人は発行対象がMozilla、発行者がComodoである、チェックに全く引っ掛からない証明書を作った模様。この手法を悪用すれば警告やエラー無しにMITM攻撃を仕掛けられると警鐘を鳴らしている。
なお、この件に関してBugzillaにも報告が挙がっている。
あ、ここだ！ (スコア:4, 興味深い)
って、こっちが顧客であって、横取りされそうになった会社の人ではないのだが。
Re:あ、ここだ！ (スコア:5, 参考になる)
私自身は、別の「安い」reseller から購入してますが、それでも最低限ということで、example.com の証明には、admin@example.com 宛のメールが受け取れないとダメよということになっています。
Re: (スコア:0)
＃今月の出来事なのでAC
Re:あ、ここだ！ (スコア:1)
Google Appsは、DNSに指定したTXTエントリを登録できるかどうかで認証するようだ。
ある意味仕方ないこと (スコア:1, すばらしい洞察)
証明書の発行者や証明書の管理者が
アホなことをやらかさない確かさ以上にはならない。
Comodoをサッと切れる体制ならよかったんだろうけど、
現実的なコストの範囲内でこういう事態に備えるのって
考えてみただけでも難しそうだなぁ。
# 値段が高ければアホをやらないという保証でもあれば
# 選ぶのも簡単なんだけどねぇ
Re:ある意味仕方ないこと (スコア:1)
ただ少し記事をあさった範囲では、問題の業者の証明書がCRL入りしているかどうかは分からなかった。
あまり続くようならもちろんComodoのルート証明書を切るという判断はありだと思うけど、
問題のある再販業者が1つあったというだけなら、厳しすぎると思う。
これがEVSSLでなければという前提で。
…個人的には(お金を扱わないようなサイト向けで)あんまり検証しない代わりに安い証明機関はいてくれる方が嬉しい。
Re:ある意味仕方ないこと (スコア:2, 参考になる)
例えばFirefoxだと、ツール(T)→オプション(O)→詳細→暗号化→証明書を表示(S)→認証局証明書→「Comodo CA Limited」以下の証明書を選択→表示(V)→詳細(D)、の順で操作して、「証明書のフィールド」の中の「Extensions」以下に「CRL Distribution Points」が存在しているかどうかを調べる。
無ければCRLは機能していない。
存在していれば、中に書いてあるURLにアクセスし、ファイルをダウンロードする。
ダウンロードしたファイルに対して、 などとやってみると中身を見ることができる。
厳密には発行者を検証したり、CP/CPSを精査したり、ということをやる必要があるでしょう。
OCSPも調べてみるべきかも。
Re:ある意味仕方ないこと (スコア:1, 参考になる)
記事からリンクしているBugzillaを少しあさればわかりますが、とっくにrevokeされています [mozilla.org]。
Re: (スコア:0)
そこに「検証された信頼できる運営者情報はありません」って表示して、
びっくりする事があります。
多分、使ってる証明書がEV(Extended Validation) SSLかどうか？って話
なんだとは思うんだけど、Yahooとかでもそう出るんですよねぇ…
EV SSLって、過去に証明書類が出された事を示すだけですからね。
正当性を主張してくれるから、脆弱性を突いたサイト乗っ取りの対象としては、
むしろカモって感じだし。
難しい話ですね。
Re: (スコア:0)
私なんかは個人にSSL証明書を発行している認証局は全てやばいと思っているので、調査した上でそういう認証局は証明書ストアから削除してオレオレ証明書と同じ扱いにしてますよ。
#こういうモノこそオプトインにすべきだと思う・・・
MozillaとComodo (スコア:1)
# もちろん、ここではMozilla = geckoということで。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo（月友）
トカゲだからこそ (スコア:2, おもしろおかしい)
トカゲだからこそ、互いにシッポを切って逃げるんです。
みなさんご利用のブラウザは (スコア:1)
iida
Re: (スコア:0)
Firefox 3.0.5…OSCP有効
IE7…「サーバー証明書の取り消しを確認する」有効
設定は変えていないのでデフォルトでこうなってるはず。
SafariとOperaとChromeは設定項目を見つけられませんでした。
Re:みなさんご利用のブラウザは (スコア:2, 参考になる)
途中までしか読んでない？ (スコア:1, すばらしい洞察)
最近、こういう投稿が目につくが、
タレコミは全部読んでからにしないか？
ブログならともかく、スラドでこういうのは勘弁してほしい。
Re:途中までしか読んでない？ (スコア:2, すばらしい洞察)
非常に問題がありそうな気がしなくもない。
物によりけり (スコア:0)
実在証明付ならザルすぎる審査なので論外ですが、
そうじゃないなら、どこに非があると責めるんでしょう…？
Re:物によりけり (スコア:2, 参考になる)
いわゆるパブリックな（ブラウザにインストールされるような）認証局の最低ラインはDV(domain validation)です。金払えば無審査でOKOKなわけではありません。
今回のCertstarはこの最低ラインを破ったからたたかれている。その区別がつかないあなたもCertstarと同レベルですね。
Re:物によりけり (スコア:1)
Re: (スコア:0, オフトピック)
$ whois certstar.com してみた (スコア:0)
Re:サーバ証明書? (スコア:3, 興味深い)
いずれの技術も、巧みなマーケティングと情報操作によって
「必要不可欠なもの」の座を見事に勝ち取った。
必要以上に一般人の不安を煽り、導入していないのは悪だ無謀だとの認識を広め、
一部の企業が莫大な利益を上げている。
たちが悪いのは、「一般的な安全性」のハードルを上げることに成功しているため、
「導入せずとも安全だ」との角度から攻めても絶対に論破できないからである。
現実世界に例えれば、空き巣の被害にあった家庭に対して、
誰もが「セコムしてなきゃ当然だ。」と思うようになってしまったようなもの。
＃ オフトピであることには変わりないですが・・・
Re:サーバ証明書? (スコア:1)
ネットワークを介した相手がどこの誰なのかを確認したい場合、実在性を正しく認証した上で発行された証明書以外に、ネットワークを介して広く一般的に利用できる方法は存在しません。
『「導入せずとも安全だ」との角度から攻めても絶対に論破できない』のは、『必要以上に一般人の不安を煽り、導入していないのは悪だ無謀だとの認識を広め』ているからではなく、その「導入せずとも安全だ」という主張自体に誤りがあるからです。
Re:サーバ証明書? (スコア:1)
空き巣の被害にあった家庭に対して、
誰もが「鍵をかけてなきゃ当然だ。」と思うようになってしまったようなもの。
ってくらいだと思います。
Re:サーバ証明書? (スコア:1)
貴方が何の事を言ってるのか判りません。
まず証明書は「普通の技術仕様を満たした鍵をかけておけば空き巣被害を防げる」ような代物では有りません。証明書は文字通り「証明書」であって「鍵」では有りません。鍵の持ち主が「どこの誰なのか」を示す物であり、その書式や意味に関する技術仕様は有っても、「どこの誰なのか」という内容に関する「確からしさ」は技術仕様の範囲外です。
証明書が示す内容については、それぞれの認証局が証明書ポリシー(CP)や認証局運用規程(CPS)によって公開する慣例になっています。少なくとも予めブラウザに「信頼できる認証局」として組み込まれている認証局については、そのCP/CPSが公開されそれに従って運用されている事、また認証局の安全を維持する上で十分な設備を備えている事といった事などが、第三者の監査により証明されている事になっています。
しかしここで重要なのは、CP/CPSで公開された内容に嘘偽りは有りませんという意味で、その認証局は「信頼できる」と言えますが、必ずしも証明書の認証手続きで発行対象の実在性は必須事項ではないという事です。ドメインの到達性を確認した上で証明書を発行するとCP/CPSに謳えば、(EV-SSL証明書でなければ)その「信頼できる認証局」はその認証方針に従った実在性を確認していない証明書を発行できるのです。
そういった証明書を受け取っても、通常はブラウザの警告は表示されません。実在性を確認していない証明書ですから、フィッシングサイトでそれを使えばパスワードなどの機密情報を盗み取る事は十分に可能です。
運用面の重要さを理解されていないのではないでしょうか。「普通の技術仕様を満たした鍵をかけておけば空き巣被害を防げる」というのは、貴方の認識不足です。
少なくとも、ベリサインはサーバ証明書として実在性を確認していない証明書は発行していませんし、またベリサインのCP/CPSは非常に緻密で十分に信頼に値すると思います。
確かに個人として購入するには高額では有りますが、その運営体制、知名度や安心感といった「ブランド力」を踏まえれば、それが重要であると考える人にはそれだけの価値は有ります。
貴方の言うような「誇大な宣伝」ではなく、それだけの実績は有ると思います。
Re:サーバ証明書? (スコア:1)
CP/CPSは誰でも確認できます。
またブラウザの「信頼できる認証局」に標準で登録されるためには、WebTrust for CAに準拠する必要が有り、それには監査会社による定期的な外部監査が求められる事になっています。
誰も確認できないというのは誤りです。
これらの枠組みは、現在の情報セキュリティの基準として頻繁に登場するBS7799に遡る事ができます。それに意味が有ると感じるか意味が無いと感じるかは本人の主観に依存しますが、「何の意味もありません」と断言する理由が「誰も確認できません」という誤った認識に基づくのなら、ちょっと勉強不足ではないでしょうか。
「ブランド力」に価値が有るかどうかは主観に基づくと思います。
しかし販売する商品自体に差異が無いのならば、それらの商品を差別化する最終的な条件が「ブランド」であるという事を知るべきでしょうね。もちろんブランドが力を持つ事ができるのは、そのブランドを確立するまでの実績が有る事は言うまでも有りません。
> （その点 EV SSL なら意味がありますが。）
なぜEV-SSL証明書なら意味が有るのですか?
EV-SSLは認証方式が標準化されているので、EV-SSLならどの認証局でも同じ認証基準で発行されているのですよ。それこそベリサインでなければならない理由は有りません。
第一、既にきちんと実在性を確認した証明書を使っているのなら、通常のSSL証明書でも相手を確認する手段として十分に条件を満たしています。ベリサインの通常の証明書でも高額すぎるという主張であるにも関わらず、それより遥かに高額なEV-SSLなら良いというのは全く理解できません。
Re:サーバ証明書? (スコア:1)
はい、仰るとおりです。しかしそれは議論の争点とは何ら関係が有りません。
サーバ証明書が
・意味のない商品(#1481277 [srad.jp])
・必要以上に一般人の不安を煽り、導入していないのは悪だ無謀だとの認識を広め(#1481316 [srad.jp])
・導入せずとも安全(#1481316 [srad.jp])
・普通の技術仕様を満たした鍵をかけておけば空き巣被害を防げる(#1481763 [srad.jp])
・(ベリサインが実在性認証された証明書しか発行していない事、CP/CPSの内容も緻密で信頼に値する事、「ブランド力」が重要であると考える人には価値が有るという事に対して)何の意味もありませんよ。誰も確認できませんから(#1482008 [srad.jp])
という物であるという主張に対する反論ですので、CP/CPSの難解さは全く関係が有りません。
逆に言えば、CP/CPSが難解である事はこれらの主張を肯定する理由にはなりません。
> それらはCAをルートに登録するのを決定するブラウザベンダや、その正しい運用状況を監視する一部の特別ユーザにとって可能になっていることに意味があるものです。
いいえ、それは違います。
然るべき資格を有した第三者による監査を実施するのは、直接の利害関係者だけに意味が有るものではなく、その監査の結果として認定される事柄を利用する全ての人に意味が有る物です。それはWebTrustのような情報セキュリティの監査だけではなく、会計監査やISO関連の監査でも同様に言える事です。
> 一般の利用者が区別しないのですから何の意味もありません。
いいえ、「一般の利用者が区別しない」のではなく「貴方が区別しない」のです。貴方は一般の利用者を代表しません。
また何らかの方法で認証局を区別する事は情報セキュリティの観点からも十分に意味が有る事です。なぜなら、サーバ証明書の信頼度は証明書を発行した認証局の信頼度を超える事は有り得ないからです。自分が信頼していない認証局が発行した証明書を避けるのはPKIを正しく認識した行動と言えますし、少なくとも「区別しない」事は推奨される事では有りません。
またサーバ証明書を利用したページを参照する利用者(検証者)が認証局を区別するかしないかは一概には言えませんが、少なくともサーバ証明書の登録者が、検証者が認証局を区別する可能性を踏まえて、登録先の認証局を区別し選択するのは一般的と言って良いです。サーバ証明書の対象サーバで取り扱う情報が高価であればなおさらの事です。
貴方が認証局を区別しない事は全く否定しませんが、認証局を区別する事が「意味が無い」と思うのは、一般論として通用する話ではなく、貴方の主観に過ぎないと知るべきです。サーバ証明書の市場占有率にそれは現れています。
> 一般の利用者が区別するからです。ブラウザが偽装不能な方法でアドレスバーに緑色で常時表示するからです。
ブラウザは通常のSSL証明書とEV-SSL証明書を区別しますが認証局を区別しません。
> その通りで、認証局にブランド価値があるかのように誤解させる詐欺まがい商法の横行が、EV SSLの登場で粉砕されるのは世の中皆にとって良いことです。
EV-SSLで認証局を区別する事は「意味が有る事」なのですか?
EV-SSLで認証局を区別する事が「粉砕されるのは世の中皆にとって良いこと」なのですか?
「意味が有る事」であるにも関わらず「粉砕されるのは世の中皆にとって良いこと」というのは、一体どういう論理なのか、支離滅裂で何を主張しているのか全く理解できません。
それとも通常のSSL証明書は「意味が無い事」であり、EV-SSL証明書は「意味が有る事」だという主張ですか?
しかしEV-SSL証明書を発行できる認証局は、通常のSSL証明書を発行できる認証局より、遥かに厳格な運営と設備が必要となります。EV-SSL証明書を発行できる一部の体力の有る認証局だけに選択肢は限られてきますし、通常のSSL証明書より遥かに高額な証明書ですから、より「ブランド力」は重視されるでしょう。仮にEV-SSL証明書が採算に合うとしたら、ベリサインだけになるように感じます。
もし、実在性認証された通常のSSL証明書は「意味が無い事」であり、EV-SSL証明書は「意味が有る事」であると貴方が感じているのなら、それこそ「EV-SSLに価値があるかのように誤解させる詐欺まがい商法の横行」が有るのではないかと感じますね。
Re:サーバ証明書? (スコア:1)
ただしドメインを取る位の安全性しか担保されていませんから、Whoisに書かれた内容が信頼できるか否かという程度の安全性でしか有りません。
安全はタダでは有りません。当然ですね。
ちなみに、そのような証明書で一体何を「証明」するというのか、またその「証明」する内容が果たして一般の利用者の「安全」に寄与しているのかと思うと甚だ疑問です。
実在性を認証していない証明書が警告も表示されずに受け入れられてしまうというのは、ドメインスクワッティングと組み合わせる事で、SSLで暗号化された中間者攻撃を容易に実現できるものです。証明書を取得する「費用」だけが攻撃者がその方法を取らない唯一の理由であり、攻撃者が期待する「利益」がその「費用」より大きいのなら、そのような証明書の存在は利用者の「安全」に寄与するどころか、むしろ「危険」に曝しているに過ぎないと思います。
Re:サーバ証明書? (スコア:1)
> 暗号化通信を実現しているじゃない。そのドメインの所有者との暗号化通信をしていることが証明される。それがSSLの基本機能でしょうが。
いいえ、それは違います。
まず一般に実在性を認証したサーバ証明書の発行対象はドメイン所有者では「ありません」。そのドメインを利用したWebサイトの運営主体となっている個人や団体です。
つまりexample.jpのドメイン登録者がnisigutiで、example.jpのドメイン名を使って/.Jが運営されているとすると、そのサーバ証明書の発行対象は/.Jであってnisigutiでは有りません。
またドメインの到達性を認証したサーバ証明書の発行対象もドメイン所有者では「ありません」。あくまでもその「ドメイン」であって、実際にはWhoisに登録者として記載された人物とは別の人かも知れません。Whois情報に正しい情報を記載するのはあくまでも紳士協定的な物であって、実在性確認をした証明書とは、信頼度は全く異なるものです。
Re:サーバ証明書? (スコア:1)
> あるべき仕様の話と、起きてしまった事故の話の区別くらいしようよ。
どうも議論が噛み合いませんね。
話の流れを見て頂ければ判ると思いますが、私の(#1481674 [srad.jp])は、その話とは直接繋がった話では有りません。
一部認証局がマッチポンプの如く不安を煽り不必要な証明書を販売しているのが実情である(#1481316 [srad.jp])という主張がなされ、その流れでそのような「胡散臭さ」は
> ドメイン取るぐらいの気軽さになれば、解消されるんじゃないですか。(#1481641 [srad.jp])
というような主張がなされたので、私はそのような気軽さで発行されるような証明書では、実際に安全を担保する事など不可能であるという反論をしています。
ドメインを取る位の気軽さで発行される証明書では、実在性を確認するような人の手を介さなければならない手間隙を掛ける事は、時間的にも経済的にも不可能です。根拠の無い「胡散臭さ」を解消するために、実在性を確認しない証明書を発行するというのは、本末転倒としか思えません。
例えばドメインを取る位の気軽さでwww.example.jpという証明書が発行されたとして、そのexample.jpというドメインの登録者がexample.comのドメイン登録者と同じだとしたら、その証明書を受け取った人はexample.jpとexample.comの同一性にはあまり疑いを持たないでしょう。
しかしexample.jpのWhoisに記載されている情報には嘘や偽りが含まれていないという保証はどこにも無いのです。example.comを攻撃目標とした攻撃者がexample.jpを取得しているかも知れない訳で、example.jpがexample.comの中間者攻撃に用いられているとしても、それをどうやって判断できるのですか?
今回の問題は、www.mozilla.comというサーバ用の証明書が、そのドメインの持ち主でない人に対して何の認証もされないまま発行されたという事です。(そういう話ですよね)
ですから、www.mozilla.comにアクセスした時に何の警告も表示されずにwww.mozilla.comの証明書を受け取ったとしても、利用者の名前解決に細工がされていれば、それはwww.mozilla.comに見せかけた攻撃者のサイトであるかも知れない、そして利用者が注意深くともそれを見破る事ができないという問題です。
私が意図している事は、ドメイン名の不正取得を利用した話であり、今回の件は不十分な認証で証明書が発行されたという事ですから、確かに両者は同じでは有りません。また前者は注意深く見れば「怪しさ」に気付くかも知れませんが、後者は注意深く見ても「怪しさ」に気付く事は難しいという違いは有るでしょう。
しかし殆どの利用者にとって、どちらも「難しくて判らない」という事に違いは無いのですから、一般の利用者に対する危険性は何ら変わりないと思います。むしろ前者は後者のように証明書が失効される事は無いのですから、前者の方が容易に実現できる上に後者より被害が大きくなる可能性も秘めていると思います。
Re:サーバ証明書? (スコア:1)
サーバ証明書とは、どのような仕組みでセキュリティを確保する物なのか、ご存知ではないのではないですか?
Re:サーバ証明書? (スコア:1, すばらしい洞察)
逆に仕組み以前に、どういう状態であれば安全（あるいは危険）なのか程度でも理解してる人がどれだけいるんでしょうか？
全体的なリテラシーの向上がない限り、どれだけ高度な仕組みがあったところでお飾りにしかならないのは事実だと思います。
Re:サーバ証明書? (スコア:1, 参考になる)
最近はそうでもないよ。Firefox 3では簡単にはスルーできなくされたし、IE 7でも派手な警告が出て、スルーしてもその後もアドレスバーが赤くなって警告が出続けるようになった。
簡単な話。入力する前にアドレスバーを確認する。そんだけ。
理解してないのはむしろ中途半端な技術知識のある人たちなんじゃないかな。サーバ証明書なんか意味ないとか言い出すような。
Re:サーバ証明書? (スコア:1)
安全は技術面だけでなく運用面も含めて考えなければ確保する事はできません。
それはサーバ証明書の問題ではなく、あらゆる「安全」に対する一般的な法則に過ぎません。
Re:サーバ証明書? (スコア:1)
>程度でも理解してる人がどれだけいるんでしょうか？
>全体的なリテラシーの向上がない限り、どれだけ高度な仕組みがあったところで
>お飾りにしかならないのは事実だと思います。
自分を守るために下調べをした人はそれなりに安全が確保されています。
複雑で高度な仕組みも全く無駄では有りません。
ただし、グダグダなサイトがSSLを使用しただけで安全だと喧伝するせいで、
一般的なユーザが、危険な目に遭う確率は昔より上がってしまったかもしれません。
最低限(ただし、どんどんレベルが上がる)の知識なしで、
世の中を渡るのが危険なのは昔から変わっていないし、
変えることができないのは当然だと思います。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
つまりだ、そもそも「ウィルスと対策ソフトと作者が同じ」って事に意味が無いんじゃないか？
Re: (スコア:0)
Re:サーバ証明書? (スコア:1)
アンチウイルスを名乗る以上、『自分が作ったものでないウイルスにも対応する必要がある』とか考えませんでしたか？
それはもう、ちょっとやそっと自作自演で泡銭稼いだくらいではとても割に合わない目に遭うこと請け合いです。
試しにやってみては？
# きょうび特定の1種類にしか対応しないようなアンチウイルスでは見向きもされないでしょうし。
## っつーかそれ『自作自演です』って言ってるようなもんだろうが。
Re: (スコア:0)
馬鹿をだますだけなら実際に何かを検出できる必要すらありませんよ。
Re:むしろ、 (スコア:1)
> どこのを使っても暗号化には全く能力は同じです。
それは半分は正しいですが、半分は誤りです。
サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は通信相手が「誰なのか」を明確にする事です。暗号化の能力は同じ(というより、むしろサーバ証明書には無関係)ですが、「誰なのか」を明確にする能力は認証局の認証方針とその信頼性に依存します。
幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。
Re:むしろ、 (スコア:1)
「通信相手がいつもの××であることの確認」をどうすれば良いのかという事が問題なのですから、「それさえ確認されれば」というのは論点が違います。
「それさえ確認されれば」というのは問題が解決した後の話であって、その場合の論点は「暗号」や「ハッシュ」の方式やビット長の話です。サーバ/クライアントの対応の話をしているのではないのですから、ここでは全く的外れです。
> なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。
それは/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません。どのようにすれば、ネットワークを介した相手が「××であるのは確からしい」と確信を持つ事ができるかという話をしているのですよ。
> 記載事項のうち common name は（相手が slashdot.jp であることを確認するために）暗号化道具にとって必須なものですが、それ以外は暗号化道具として必要でないものです。
それは根本的に誤っています。狭義の暗号化の話ならば、コモンネームは必要では有りません。
警告が表示される事が有ったとしても、その警告が意図した物であり、通信相手が目的の相手である事に確信が有るのならば、その証明書を受け入れれば通常通り暗号化通信が行われます。
コモンネームは通信相手が目的とする相手であるか確認するために必要ですが、問題はコモンネームが本当に目的の通信相手なのかという事です。
> common name の確認が行われるために認証局に求められるのは、slashdot.jp 以外の人にサーバ証明書を発行しないことです。これは必須の要件でありこれを満たさないのは認証局として論外（今回の事件のケース）です。
はい、それはその通りです。
公的な認証局として、それは必須要件でしょう。
> それが守られていれば、あとはどこの認証局も同じでブランドは無意味です。
いいえ、それは違います。
貴方が言っているのは「必要条件」であって「十分条件」では有りません。
公的な認証局が「必要条件」を満たさないのは貴方の仰るように「論外」ですが、「必要条件」を満たしている事は公的な認証局として「十分条件」を満たす事を意味しません。
公的な認証局は、「互いに知らない者同士」が通信する上で「信頼できる第三者」としての役割を担います。「通信相手がいつもの××であることの確認」ができる事が期待されているのですから、「コモンネーム以外も正しい事が求められる場面」も有るのですよ。
そしてインターネットにおいて金銭的な情報や機密情報をやり取りするのは、その「コモンネーム以外も正しい事が求められる場面」なのです。
> 無関係？まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか？
同じですよ。TLS/SSLではサーバ/クライアント間の暗号方式はサーバ/クライアント間の折衝で決定されます。
サーバ証明書は「公開鍵証明書」と呼ばれる物ですが、公開鍵証明書が直接関係する暗号方式は文字通り公開鍵暗号です。公開鍵暗号はTLS/SSLの通信が確立する迄のサーバ/クライアント間の折衝において利用されますが、TLS/SSL通信が確立した後はサーバ/クライアント間の折衝で決定された共通鍵において暗号化されます。
ですからベリサインが発行した証明書でも、プライベートCAが発行した証明書でも、それらを利用するWebサーバ/Webブラウザの組み合わせが同じならば、暗号強度に全く差異は有りません。
ですから、最初に貴方が挙げた例「通信相手がいつものslashdot.jpであることの確認であり、それさえ確認されれば」で言えば、slashdot.jpのプライベートCAが発行した証明書で何ら問題は有りません。
> 暗号化道具としてのSSLにとって実在証明は無関係であり、実在証明はサーバ証明書販売のついでに付け加えた付加機能です。
どうやら「暗号化されていれば安全である」という誤解、あるいはSSLの対象として「貴方の想定された用途を満たせば十分である」という誤解をなさっているように思います。「暗号化道具としてのSSL」ではなく、PKIの仕組みを勉強し直されるとより理解が深まるように思います。
PKIを理解してくれる人が増える事は大歓迎ですので、私としては貴方には是非そうして頂きたいですね。
Re:むしろ、 (スコア:1)
貴方と同じ方法です。
しかし/.にログインする話と、例えば銀行のオンラインバンクにログインする話では、その重要性は全く違います。銀行のオンラインバンクが別の銀行と共同で利用しているような場合には、銀行のその他のページとは別のドメインで運用されている事も有ります。それが「いつも使っている銀行のオンラインバンクであるのは確からしい」と確信をどうやって持てるのかという話です。
>>> 無関係？まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか？
>>同じですよ。slashdot.jpのプライベートCAが発行した証明書で何ら問題は有りません。
>これはひどい。そこまで無知な人と話をしているとは思いませんでした。お話しになりまん。さようなら。
何が酷くて無知なのか、さっぱり理解できません。
実際にベリサイン、サイバートラスト、RSAをルートとする中間認証局、プライベートCAのそれぞれが発行した証明書を使っていますが、私の知っている環境(サーバ/クライアントがApache/Operaの組み合わせ)ならそのどれを使っても暗号化通信はAES256bitで行われます。
「暗号化能力」って何の話をしているのですか?
Re:むしろ、 (スコア:1)
> 私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。
いや、間違いでは有りませんよ。
もちろん利用者が直感的に判りやすいという意味ではそうすべきという考え方も有りますが、全てのWebサイトを同じドメイン名で運営できるとは限りませんよね。Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。オンラインバンクに限らず、認証ページだけ別のWebサイトというのも有り得る話だと思います。
第一、httpで運営されているWebサイトとhttpsで運営されているWebサイトが、同一の運営主体であるという確認をするのは、片方にしか証明書が存在しない以上、確実性に乏しい事は間違い無いと思います。
> 私だったら別のドメインで運用している銀行は使わないです。
> もっともそういうのは地方銀行の一部だけのようですが。
そうですね。そういう考え方も有ると思います。
Re:むしろ、 (スコア:1)
> 実際IBMのASPはそうしているようですよ。
いいえ、それは一概には言えません。
名前ベースのバーチャルドメインでは、サーバ証明書の運用は技術的な仕様により困難です。
> いえいえ、バーチャルホストなら負荷の問題はありませんし、
> IPベースバーチャルホストなら SSLも普通に使えます。
いや、私が申し上げているのは、もっと広い意味での運営体制です。
Webサーバの運用体制というより、何らかのサービスを提供するWebサイトを維持し運営する体制といった事を想定しており、サービス毎に別々のドメイン名を使う事や、負荷分散のために機能的にサーバ分けたり、或いは機能や価格を考慮して外部のASPサービスを部分的に利用する事など、「ドメイン認証のサーバ証明書を利用する」という目的にもならない目的のためにドメイン名を統一する事より、他に優先される事が多いのではないかという事を言っています。
オンラインバンクだけに限った話をしている訳ではありません。
> それで、その場合に、認証ページのサーバ証明書のサブジェクトは銀行名に
> なるんでしょうか？ ならないようですが？
それはオンラインバンクの実例ではしていないというだけであって、実在認証されたサーバ証明書としてはできるものですよ。
servicename.comの認証ページがcompanyname.comでも良いですよね。
Re:むしろ、 (スコア:1)
> のに、IPベースバーチャルホストを知らないのですか？
知っています。
しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか? またあくまでも可能性の話ならば、仮にIPベースの実装であっても独自ドメイン名によるサーバ証明書の運用が認められ、商品として提供されているとは限りません。
技術的に問題が無い事は全ての問題が解決した事を意味しません。
何にしても、貴方が仰っているのは「IPベースバーチャルホストなら」という条件下でのみ通用する話であって、私が言っているのはそういう条件に合致しない場合も有りますよね、という話なのです。以前に(別の方に対してかも知れませんが)「/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません」という事を言いましたが、そのようにある限定された条件下の話をしているのではないんです。
> 実在証明付きサーバ証明書を必要とするようなサイトが、そんな
> 安かろう悪かろうのサービスを選択すること自体が間違いですね。
それは貴方の主観に過ぎません。
私の印象としては、広く一般向けのサイトであるにも関わらず、自らの身元も明らかにせずドメイン認証の証明書で運用している方が、よほど「安かろう悪かろうのサービス」だとしか思えませんね。仮想ドメインの実装が名前ベースかIPベースかなど、サイトの利用者には確認できない話ですし、直接関係の無い話です。
第一、広く一般向けのサイトに使う事を目的として、ドメイン認証しかされていない証明書を販売している公的認証局は有るんですか? 建前としては、ドメイン認証の証明書は組織内など限られた範囲で使う事を目的としていたと思います。それなら接続先のサイトが「どこの誰か」は予め判っている事ですので、ドメイン認証の証明書でもセキュリティ上の問題は有りません。
# ただ限られた範囲で使うのなら、プライベートCAでも全く問題は有りません。
>> 他に優先される事が多いのではないかという事を言っています。
> そんなものはありませんよ。
もっと社会を勉強しましょう。
> 言っていることがおかしいですよ。ASP利用で他社管理のサーバを使わざるを得ない
> からという話をしているのに、どうして、認証ページのサーバ証明書のサブジェクトが
> 自社のものにできるのですか？
「ASP利用で他社管理のサーバを使わざるを得ないからという話」*のみ*をしているのでは有りません。私はドメイン名を統一できない状況の一例としてそれを挙げていただけであり、サービス提供サイトと認証サイトが同一企業の別ドメインという事も想定しています。
「servicename.comの認証ページがcompanyname.comでも良いですよね」というのは、「サービス毎に別々のドメイン名」を運用している企業を意図していました。
前にも少し触れましたが、もっと基本的なPKIの仕組みから理解するべきだと思います。
TLS/SSLはPKI(公開鍵暗号基盤)の実装です。そうであるにも関わらず「基盤」である事を無視して、TLS/SSLを単なる「暗号化道具」と考えるのは過剰に単純化した見方であり、正しい理解の仕方では有りません。逆に言えば、TLS/SSLが単なる「暗号化道具」なら過剰品質も甚だしい「大袈裟過ぎる」代物としか思えません。
# その程度のものなら苦労しませんよ。(-_-;
Re:むしろ、 (スコア:1)
サーバ証明書はそのサイトの運営主体に発行され、そのサイトの運営主体をSubjectに記載します。
「servicename.comの認証ページがcompanyname.comでも良いですよね」
その両方がA社の物で両方ともhttpsで運営するなら、両方のサーバ証明書のSubjectにはA社が記載される事になります。
貴方こそ、私には一体何が言いたいのか判りません。
詐欺まがい商法というのは、貴方の歪んだ主観に過ぎません。
> ハア？主従が逆だよ。PKIのためにTLSがあるんじゃなくて、TLSで達成したいこと（end-to-endの暗号化通信）を実現するためにPKIの仕組みを活用しているだけ。
逆でも何でも有りません。同じ事を言っています。
TLSで達成したい事は狭義の暗号化だけではないという事です。それを貴方が理解されていないだけです。
> TLSは仕様として Subject の CN だけ検証することになっていて、ぶっちゃけ O とか TLSの目的状は無用。
違います。TLS/SSLの検証はもっと複雑です。
拡張領域のSubjectAltnativeNameに記載が有ればそれも検証対象となりますし、証明書の有効期限も考慮されます。また証明書の失効情報を利用する場合は、証明書の失効情報やその失効情報自体の有効期限も考慮されます。それらの情報を発行した認証局についてそれと同様の検証が為され、更に発行された証明書を発行する資格が認証局に有るかどうかを含めて、検証者の信頼ポイントまで遡るように行われます。
Subjectに記載されたその他の情報は、貴方が無用と感じているだけです。
貴方は全ての利用者を代表する者では有りません。
> ベリサインとかあなた方のような実在証明を売りにしている証明書販売業者は、TLSの必要性にかこつけて、それとは独立した無関係の機能を押し売りしているだけ。
別に押し売りなどしていません。
「詐欺まがい」だの「押し売り」だのと仰いますが、まるで事実とは異なります。
要するに他の大勢の人が認める価値を貴方が認めていないだけです。
> あなた、いまだにTLS的な end-to-end の暗号化通信のために、自己署名証明書で十分とか勘違いしているわけ？
私は「TLS的な end-to-end の暗号化通信のために、自己署名証明書で十分」などと言った事は有りません。*ネットワークを介した相手が「どこの誰か」明確である場合ならば*、プライベートCAの発行した証明書でも何らセキュリティ上の問題は無いという事を言っています。認証局がパブリックであろうがプライベートであろうが、実際のデータ通信で選択される暗号の種類とビット長は何ら変わりません。
何が「勘違い」なのか具体的に指摘して下さい。
更に言えば、実在認証を否定しサーバ証明書のコモンネーム以外の情報を否定しているにも関わらず、プライベートCAを否定するのは矛盾しています。
認証局の証明書もエンドエンティティの証明書も、一部の情報が異なるだけで同じ書式の証明書です。WebTrust for CAに準拠した認証局は、全て「実在認証された証明書」で運営されています。実在認証を否定しSubject CNが合致していれば十分であるというのならば、プライベートCAの実在認証されていない認証局証明書でもそれで「十分」です。否定する理由が有りません。
Re:むしろ、 (スコア:1)
公開鍵と共通鍵の使い分け、X.509証明書の書式、検証者が行う証明書の検証手順、PKIにおける信頼できる第三者の役割などは、TLS/SSLの技術論を議論するためには必要な事です。
しかし、どうやら散々文句を言っていた匿名の臆病者は、単にそれらの知識が足りない人のようですね。彼の主張はそれらの技術的裏づけも客観的な事実の裏付けもなく、彼の主張に反論しても無視されますし、彼が主張する「勘違い」についても結局具体的な指摘もできないようです。
散々人をこき下ろしておいて最後がこれとは実に無責任。匿名でも臆病者でも結構ですが、発言した事の責任を果たせないのなら、発言しないで頂きたい。