パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Comodo CAがサーバ証明書を関係のない第三者に発行、大問題に」記事へのコメント

  • by Anonymous Coward
    こういう業者がたくさんいることで、ベリサインなどの業者が証明書を高い値段で売りつけることが出来るようになるわけで、単にいなくなれば良いというわけでもないでしょう。

    # というか、上場企業の証明書が、エロサイトと同じ発行元だったらそれはそれで常識を疑う。良いか悪いかは別として。

    • by Anonymous Coward

      上場企業の証明書が、エロサイトと同じ発行元だったらそれはそれで常識を疑う。良いか悪いかは別として。

      いや、全然疑わない。サーバ証明書は単なる暗号化の道具ですよ?
      どこのを使っても暗号化には全く能力は同じです。

      • by nisiguti (1286) on 2008年12月29日 0時57分 (#1482497)
        > いや、全然疑わない。サーバ証明書は単なる暗号化の道具ですよ?
        > どこのを使っても暗号化には全く能力は同じです。

        それは半分は正しいですが、半分は誤りです。

        サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は通信相手が「誰なのか」を明確にする事です。暗号化の能力は同じ(というより、むしろサーバ証明書には無関係)ですが、「誰なのか」を明確にする能力は認証局の認証方針とその信頼性に依存します。

        幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。
        親コメント
        • by Anonymous Coward

          幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。

          相手がどこの誰かなんて必要でありません。slashdot.jp を利用するときに必要なのは通信相手がいつもの slashdot.jp であることの確認であり、それさえ確認されれば(多くの人にとって)十分であり、中の人がどこの会社かということなど確認を必要としていません。なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。

          サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は

          • by nisiguti (1286) on 2008年12月29日 20時59分 (#1482913)
            > 相手がどこの誰かなんて必要でありません。slashdot.jp を利用するときに必要なのは通信相手がいつもの slashdot.jp であることの確認であり、それさえ確認されれば(多くの人にとって)十分であり、中の人がどこの会社かということなど確認を必要としていません。

            「通信相手がいつもの××であることの確認」をどうすれば良いのかという事が問題なのですから、「それさえ確認されれば」というのは論点が違います。

            「それさえ確認されれば」というのは問題が解決した後の話であって、その場合の論点は「暗号」や「ハッシュ」の方式やビット長の話です。サーバ/クライアントの対応の話をしているのではないのですから、ここでは全く的外れです。

            > なぜなら、既に 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を理解してくれる人が増える事は大歓迎ですので、私としては貴方には是非そうして頂きたいですね。
            親コメント
            • by Anonymous Coward

              > なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。

              それは/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません。どのようにすれば、ネットワークを介した相手が「××であるのは確からしい」と確信を持つ事ができるかという話をしているのですよ。

              なら、あなたはどうやって今 slashdot.jp にログインしてそれを書き込んだのですか?

              > 無関係?まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか?

              同じですよ。slashdot.jpのプライベートCAが発行した証明書で何ら問題は有りません。

              これはひどい。そこまで無知な人と話をしているとは思いませんでした。お話しになりまん。さようなら。

              • by nisiguti (1286) on 2008年12月30日 6時39分 (#1483086)
                > なら、あなたはどうやって今 slashdot.jp にログインしてそれを書き込んだのですか?

                貴方と同じ方法です。

                しかし/.にログインする話と、例えば銀行のオンラインバンクにログインする話では、その重要性は全く違います。銀行のオンラインバンクが別の銀行と共同で利用しているような場合には、銀行のその他のページとは別のドメインで運用されている事も有ります。それが「いつも使っている銀行のオンラインバンクであるのは確からしい」と確信をどうやって持てるのかという話です。

                >>> 無関係?まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか?
                >>同じですよ。slashdot.jpのプライベートCAが発行した証明書で何ら問題は有りません。
                >これはひどい。そこまで無知な人と話をしているとは思いませんでした。お話しになりまん。さようなら。

                何が酷くて無知なのか、さっぱり理解できません。

                実際にベリサイン、サイバートラスト、RSAをルートとする中間認証局、プライベートCAのそれぞれが発行した証明書を使っていますが、私の知っている環境(サーバ/クライアントがApache/Operaの組み合わせ)ならそのどれを使っても暗号化通信はAES256bitで行われます。

                「暗号化能力」って何の話をしているのですか?
                親コメント
              • by Anonymous Coward
                横から失礼します。

                > 銀行のその他のページとは別のドメインで運用されている事も有ります。
                > それが「いつも使っている銀行のオンラインバンクであるのは確からしい」
                > と確信をどうやって持てるのかという話です。

                別のドメインで運用するのが間違いではないでしょうか。
                私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。
                私だったら別のドメインで運用している銀行は使わないです。
                もっともそういうのは地方銀行の一部だけのようですが。
              • by nisiguti (1286) on 2008年12月31日 15時45分 (#1483749)
                > 別のドメインで運用するのが間違いではないでしょうか。
                > 私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。

                いや、間違いでは有りませんよ。

                もちろん利用者が直感的に判りやすいという意味ではそうすべきという考え方も有りますが、全てのWebサイトを同じドメイン名で運営できるとは限りませんよね。Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。オンラインバンクに限らず、認証ページだけ別のWebサイトというのも有り得る話だと思います。

                第一、httpで運営されているWebサイトとhttpsで運営されているWebサイトが、同一の運営主体であるという確認をするのは、片方にしか証明書が存在しない以上、確実性に乏しい事は間違い無いと思います。

                > 私だったら別のドメインで運用している銀行は使わないです。
                > もっともそういうのは地方銀行の一部だけのようですが。

                そうですね。そういう考え方も有ると思います。
                親コメント
              • by Anonymous Coward
                > 全てのWebサイトを同じドメイン名で運営できるとは限りませんよね。

                いや、できますよ。ASP利用でもDNS設定すればいいことだし、
                実際IBMのASPはそうしているようですよ。

                > Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。

                いえいえ、バーチャルホストなら負荷の問題はありませんし、
                IPベースバーチャルホストなら SSLも普通に使えます。
                地方銀行がやっていないのは ASP会社のNTTデータが怠慢なだけですね。

                > オンラインバンクに限らず、認証ページだけ別のWebサイトというのも
                > 有り得る話だと思います。

                それで、その場合に、認証ページのサーバ証明書のサブジェクトは銀行名に
                なるんでしょうか? ならないようですが?
              • by nisiguti (1286) on 2009年01月01日 1時10分 (#1483945)
                > いや、できますよ。ASP利用でもDNS設定すればいいことだし、
                > 実際IBMのASPはそうしているようですよ。

                いいえ、それは一概には言えません。
                名前ベースのバーチャルドメインでは、サーバ証明書の運用は技術的な仕様により困難です。

                > いえいえ、バーチャルホストなら負荷の問題はありませんし、
                > IPベースバーチャルホストなら SSLも普通に使えます。

                いや、私が申し上げているのは、もっと広い意味での運営体制です。

                Webサーバの運用体制というより、何らかのサービスを提供するWebサイトを維持し運営する体制といった事を想定しており、サービス毎に別々のドメイン名を使う事や、負荷分散のために機能的にサーバ分けたり、或いは機能や価格を考慮して外部のASPサービスを部分的に利用する事など、「ドメイン認証のサーバ証明書を利用する」という目的にもならない目的のためにドメイン名を統一する事より、他に優先される事が多いのではないかという事を言っています。

                オンラインバンクだけに限った話をしている訳ではありません。

                > それで、その場合に、認証ページのサーバ証明書のサブジェクトは銀行名に
                > なるんでしょうか? ならないようですが?

                それはオンラインバンクの実例ではしていないというだけであって、実在認証されたサーバ証明書としてはできるものですよ。

                servicename.comの認証ページがcompanyname.comでも良いですよね。
                親コメント
              • by Anonymous Coward
                > 名前ベースのバーチャルドメインでは、サーバ証明書の運用は技術的な
                > 仕様により困難です。

                だから、「IPベースバーチャルホストなら SSLも普通に使えます」と言った
                のに、IPベースバーチャルホストを知らないのですか?

                > 負荷分散のために機能的にサーバ分けたり、

                IPベースバーチャルホストで解決すると言っているんですけど?

                > 或いは機能や価格を考慮して外部のASPサービスを部分的に利用する事など

                実在証明付きサーバ証明書を必要とするようなサイトが、そんな
                安かろう悪かろうのサービスを選択すること自体が間違いですね。

                > 他に優先される事が多いのではないかという事
              • by nisiguti (1286) on 2009年01月01日 7時07分 (#1484013)
                > だから、「IPベースバーチャルホストなら SSLも普通に使えます」と言った
                > のに、IPベースバーチャルホストを知らないのですか?

                知っています。

                しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか? またあくまでも可能性の話ならば、仮にIPベースの実装であっても独自ドメイン名によるサーバ証明書の運用が認められ、商品として提供されているとは限りません。
                技術的に問題が無い事は全ての問題が解決した事を意味しません。

                何にしても、貴方が仰っているのは「IPベースバーチャルホストなら」という条件下でのみ通用する話であって、私が言っているのはそういう条件に合致しない場合も有りますよね、という話なのです。以前に(別の方に対してかも知れませんが)「/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません」という事を言いましたが、そのようにある限定された条件下の話をしているのではないんです。

                > 実在証明付きサーバ証明書を必要とするようなサイトが、そんな
                > 安かろう悪かろうのサービスを選択すること自体が間違いですね。

                それは貴方の主観に過ぎません。

                私の印象としては、広く一般向けのサイトであるにも関わらず、自らの身元も明らかにせずドメイン認証の証明書で運用している方が、よほど「安かろう悪かろうのサービス」だとしか思えませんね。仮想ドメインの実装が名前ベースかIPベースかなど、サイトの利用者には確認できない話ですし、直接関係の無い話です。

                第一、広く一般向けのサイトに使う事を目的として、ドメイン認証しかされていない証明書を販売している公的認証局は有るんですか? 建前としては、ドメイン認証の証明書は組織内など限られた範囲で使う事を目的としていたと思います。それなら接続先のサイトが「どこの誰か」は予め判っている事ですので、ドメイン認証の証明書でもセキュリティ上の問題は有りません。

                # ただ限られた範囲で使うのなら、プライベートCAでも全く問題は有りません。

                >> 他に優先される事が多いのではないかという事を言っています。
                > そんなものはありませんよ。

                もっと社会を勉強しましょう。

                > 言っていることがおかしいですよ。ASP利用で他社管理のサーバを使わざるを得ない
                > からという話をしているのに、どうして、認証ページのサーバ証明書のサブジェクトが
                > 自社のものにできるのですか?

                「ASP利用で他社管理のサーバを使わざるを得ないからという話」*のみ*をしているのでは有りません。私はドメイン名を統一できない状況の一例としてそれを挙げていただけであり、サービス提供サイトと認証サイトが同一企業の別ドメインという事も想定しています。
                「servicename.comの認証ページがcompanyname.comでも良いですよね」というのは、「サービス毎に別々のドメイン名」を運用している企業を意図していました。

                前にも少し触れましたが、もっと基本的なPKIの仕組みから理解するべきだと思います。

                TLS/SSLはPKI(公開鍵暗号基盤)の実装です。そうであるにも関わらず「基盤」である事を無視して、TLS/SSLを単なる「暗号化道具」と考えるのは過剰に単純化した見方であり、正しい理解の仕方では有りません。逆に言えば、TLS/SSLが単なる「暗号化道具」なら過剰品質も甚だしい「大袈裟過ぎる」代物としか思えません。

                # その程度のものなら苦労しませんよ。(-_-;
                親コメント
              • by Anonymous Coward

                しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか?

                で、そのときに、(詐欺まがいの商法で売りつけている)サーバ証明書の実在証明で、その会社の会社名が Subject に記載されるのですか?されないでしょ?いったい何が言いたいの?

                TLS/SSLはPKI(公開鍵暗号基盤)の実装です。そうであるにも関わらず「基盤」である事を無視して、T

              • by nisiguti (1286) on 2009年01月02日 7時05分 (#1484318)
                > で、そのときに、(詐欺まがいの商法で売りつけている)サーバ証明書の実在証明で、その会社の会社名が Subject に記載されるのですか?されないでしょ?いったい何が言いたいの?

                サーバ証明書はそのサイトの運営主体に発行され、そのサイトの運営主体を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の実在認証されていない認証局証明書でもそれで「十分」です。否定する理由が有りません。
                親コメント
              • by nisiguti (1286) on 2009年01月07日 5時55分 (#1486589)
                全く返事がありませんね…。

                公開鍵と共通鍵の使い分け、X.509証明書の書式、検証者が行う証明書の検証手順、PKIにおける信頼できる第三者の役割などは、TLS/SSLの技術論を議論するためには必要な事です。
                しかし、どうやら散々文句を言っていた匿名の臆病者は、単にそれらの知識が足りない人のようですね。彼の主張はそれらの技術的裏づけも客観的な事実の裏付けもなく、彼の主張に反論しても無視されますし、彼が主張する「勘違い」についても結局具体的な指摘もできないようです。

                散々人をこき下ろしておいて最後がこれとは実に無責任。匿名でも臆病者でも結構ですが、発言した事の責任を果たせないのなら、発言しないで頂きたい。
                親コメント

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

処理中...