アカウント名:
パスワード:
上場企業の証明書が、エロサイトと同じ発行元だったらそれはそれで常識を疑う。良いか悪いかは別として。
いや、全然疑わない。サーバ証明書は単なる暗号化の道具ですよ？ どこのを使っても暗号化には全く能力は同じです。
幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。
相手がどこの誰かなんて必要でありません。slashdot.jp を利用するときに必要なのは通信相手がいつもの slashdot.jp であることの確認であり、それさえ確認されれば（多くの人にとって）十分であり、中の人がどこの会社かということなど確認を必要としていません。なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。
サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は
> なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。 それは/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません。どのようにすれば、ネットワークを介した相手が「××であるのは確からしい」と確信を持つ事ができるかという話をしているのですよ。
> なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。
それは/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません。どのようにすれば、ネットワークを介した相手が「××であるのは確からしい」と確信を持つ事ができるかという話をしているのですよ。
なら、あなたはどうやって今 slashdot.jp にログインしてそれを書き込んだのですか？
> 無関係？まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか？ 同じですよ。slashdot.jpのプライベートCAが発行した証明書で何ら問題は有りません。
> 無関係？まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか？
同じですよ。slashdot.jpのプライベートCAが発行した証明書で何ら問題は有りません。
これはひどい。そこまで無知な人と話をしているとは思いませんでした。お話しになりまん。さようなら。
しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか?
で、そのときに、（詐欺まがいの商法で売りつけている）サーバ証明書の実在証明で、その会社の会社名が Subject に記載されるのですか？されないでしょ？いったい何が言いたいの？
TLS/SSLはPKI(公開鍵暗号基盤)の実装です。そうであるにも関わらず「基盤」である事を無視して、T
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
むしろ、 (スコア:0)
# というか、上場企業の証明書が、エロサイトと同じ発行元だったらそれはそれで常識を疑う。良いか悪いかは別として。
Re: (スコア:0)
いや、全然疑わない。サーバ証明書は単なる暗号化の道具ですよ？
どこのを使っても暗号化には全く能力は同じです。
Re: (スコア:1)
> どこのを使っても暗号化には全く能力は同じです。
それは半分は正しいですが、半分は誤りです。
サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は通信相手が「誰なのか」を明確にする事です。暗号化の能力は同じ(というより、むしろサーバ証明書には無関係)ですが、「誰なのか」を明確にする能力は認証局の認証方針とその信頼性に依存します。
幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。
Re: (スコア:0)
相手がどこの誰かなんて必要でありません。slashdot.jp を利用するときに必要なのは通信相手がいつもの slashdot.jp であることの確認であり、それさえ確認されれば（多くの人にとって）十分であり、中の人がどこの会社かということなど確認を必要としていません。なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。
Re: (スコア:1)
「通信相手がいつもの××であることの確認」をどうすれば良いのかという事が問題なのですから、「それさえ確認されれば」というのは論点が違います。
「それさえ確認されれば」というのは問題が解決した後の話であって、その場合の論点は「暗号」や「ハッシュ」の方式やビット長の話です。サーバ/クライアン
Re: (スコア:0)
なら、あなたはどうやって今 slashdot.jp にログインしてそれを書き込んだのですか？
これはひどい。そこまで無知な人と話をしているとは思いませんでした。お話しになりまん。さようなら。
Re: (スコア:1)
貴方と同じ方法です。
しかし/.にログインする話と、例えば銀行のオンラインバンクにログインする話では、その重要性は全く違います。銀行のオンラインバンクが別の銀行と共同で利用しているような場合には、銀行のその他のページとは別のドメインで運用されている事も有ります。それが「いつも使っている銀行のオンラインバンクであるのは確からしい」と確信をどうやって持てるのかという話です。
>>> 無関係？まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか？
Re: (スコア:0)
> 銀行のその他のページとは別のドメインで運用されている事も有ります。
> それが「いつも使っている銀行のオンラインバンクであるのは確からしい」
> と確信をどうやって持てるのかという話です。
別のドメインで運用するのが間違いではないでしょうか。
私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。
私だったら別のドメインで運用している銀行は使わないです。
もっともそういうのは地方銀行の一部だけのようですが。
Re: (スコア:1)
> 私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。
いや、間違いでは有りませんよ。
もちろん利用者が直感的に判りやすいという意味ではそうすべきという考え方も有りますが、全てのWebサイトを同じドメイン名で運営できるとは限りませんよね。Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。オンラインバンクに限らず、認証ページだけ別のWebサイトというのも有り得る話だと思います。
第一、httpで運営されているWebサイトとhttpsで運営されているWebサイトが、同一の運営主体であるという確認をするのは、片方にしか証明書が存在しない以上、確実性に乏しい事は間違い無いと思います。
> 私だったら別のドメインで運用している銀行は使わないです。
> もっともそういうのは地方銀行の一部だけのようですが。
そうですね。そういう考え方も有ると思います。
Re: (スコア:0)
いや、できますよ。ASP利用でもDNS設定すればいいことだし、
実際IBMのASPはそうしているようですよ。
> Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。
いえいえ、バーチャルホストなら負荷の問題はありませんし、
IPベースバーチャルホストなら SSLも普通に使えます。
地方銀行がやっていないのは ASP会社のNTTデータが怠慢なだけですね。
> オンラインバンクに限らず、認証ページだけ別のWebサイトというのも
> 有り得る話だと思います。
それで、その場合に、認証ページのサーバ証明書のサブジェクトは銀行名に
なるんでしょうか？ ならないようですが？
Re: (スコア:1)
> 実際IBMのASPはそうしているようですよ。
いいえ、それは一概には言えません。
名前ベースのバーチャルドメインでは、サーバ証明書の運用は技術的な仕様により困難です。
> いえいえ、バーチャルホストなら負荷の問題はありませんし、
> IPベースバーチャルホストなら SSLも普通に使えます。
いや、私が申し上げているのは、もっと広い意味での運営体制です。
Webサーバの運用体制というより、何らかのサービスを提供するWebサイトを維持し運営する体制といった事を想定しており、サービス毎に別々のド
Re: (スコア:0)
> 仕様により困難です。
だから、「IPベースバーチャルホストなら SSLも普通に使えます」と言った
のに、IPベースバーチャルホストを知らないのですか？
> 負荷分散のために機能的にサーバ分けたり、
IPベースバーチャルホストで解決すると言っているんですけど？
> 或いは機能や価格を考慮して外部のASPサービスを部分的に利用する事など
実在証明付きサーバ証明書を必要とするようなサイトが、そんな
安かろう悪かろうのサービスを選択すること自体が間違いですね。
> 他に優先される事が多いのではないかという事
Re: (スコア:1)
> のに、IPベースバーチャルホストを知らないのですか？
知っています。
しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか? またあくまでも可能性の話ならば、仮にIPベースの実装であっても独自ドメイン名によるサーバ証明書の運用が
Re: (スコア:0)
で、そのときに、（詐欺まがいの商法で売りつけている）サーバ証明書の実在証明で、その会社の会社名が Subject に記載されるのですか？されないでしょ？いったい何が言いたいの？
Re: (スコア:1)
サーバ証明書はそのサイトの運営主体に発行され、そのサイトの運営主体をSubjectに記載します。
「servicename.comの認証ページがcompanyname.comでも良いですよね」
その両方がA社の物で両方ともhttpsで運営するなら、両方のサーバ証明書のSubjectにはA社が記載される事になります。
貴方こそ、私には一体何が言いたいのか判りません。
詐欺まがい商法というのは、貴方の歪んだ主観に過ぎません。
Re:むしろ、 (スコア:1)
公開鍵と共通鍵の使い分け、X.509証明書の書式、検証者が行う証明書の検証手順、PKIにおける信頼できる第三者の役割などは、TLS/SSLの技術論を議論するためには必要な事です。
しかし、どうやら散々文句を言っていた匿名の臆病者は、単にそれらの知識が足りない人のようですね。彼の主張はそれらの技術的裏づけも客観的な事実の裏付けもなく、彼の主張に反論しても無視されますし、彼が主張する「勘違い」についても結局具体的な指摘もできないようです。
散々人をこき下ろしておいて最後がこれとは実に無責任。匿名でも臆病者でも結構ですが、発言した事の責任を果たせないのなら、発言しないで頂きたい。