• ベストアンサー

SSLそのものとベリサイン等の認証局の関係

noname#14035の回答

  • ベストアンサー
noname#14035
noname#14035
回答No.4

#2のJzamraiです。 さて、他の回答(書き込み)を受けての補足回答は本サイトの主旨に反しかねないとは思いますが、あくまで「回答者や閲覧者にとっての利益」に繋がると信じる(話の本質をより良く理解していただく為の)補足説明を私の方からはさせてください。 #3のsuzuiさんのご指摘、 ↓ >>有償のサーバIDは、信頼されたいから使うというよりは、リスクを軽減させるために使うのです。 >>これは嘘ではありませんが、リスクの考慮が不足していると思います。その点はNo.2さんも明確にされていません。 いわゆる「専門家」の方のご意見・ご指摘、私も有難く拝読しましたが、このように断言されてしまうと、正直少々違和感を覚えます。 suzuiさんご紹介の専門家(高木浩光 氏)による下記のブログは、様々な解説や考察(PKIやプライバシーに関する技術論もふくめ)、氏の博識や経験に裏づけされた、関連分野に関心を持つ者にとって非常に有益な内容のものであると私も感じます。 私自身、多大なる恩恵を受けている一人で、定期巡回先とさせていただいています。(ちなみに、nikuqさんの言及されている「公的機関による認証の(惨状!?)じゃなくて”現状”」についての考察(わが国では自治体ベースの話が多いですが。)も読む事が出来ますヨ。) ■高木浩光@自宅の日記■ ↓ http://takagi-hiromitsu.jp/diary/20041112.html これは、日ごろ私が情報セキュリティーについて強く感じていて、関連する話をする際に常に念頭においていることなのですが、 ↓ >公人(インターネット上のノードを運用する組織)として、全体的なポリシーをもとに、採用する対策技術についても正しい理解につとめ、これらを正しく管理・運用し続ける事。 ↓ >それが有効なリスク軽減策となり、安全な(サイト)運営につながるという事実。(「自組織のリスクヘッジ」と「利用者の安全」という価値提供を可能にする。) ↓ >ひいては、それが当該組織の利益や信用・信頼の獲得につながるという考え方。(リスクヘッジを含めた損得勘定と社会的責任を両立させるという点で。) ↓ 上記の内容は、情報セキュリティーについての話の重要な柱ではないかと思っています。(もちろん、さまざまな視点があってしかるべきですが。) 情報セキュリティーの話をする以上、「リスクと利便性の天秤」(利便性を損なわない範囲で、リスクの最小化を目指す。)という考え方は、誰もが当然年頭に置いておくべきことで、#1のanmochiさんのご解説も、当然そうした背景を意識されて記入いるはずだと思います。(私の邪推かもしれませんが…。) 社会への普及と自然検証によってその有効性を認められている様々なセキュリティー対策については、そのすべてに「リスク・ヘッジ」の考え方を(大なり小なり)反映しているものだと思います。(各組織別の要件に対して、これらの技術を最適な形で複合的に組み合わせた上で、有効に機能させるという考えかたも重要でしょう。) 公人(組織)であれば、「訴訟対策(民事・刑事双方の)」を含めたリスクヘッジを考えるのは当然のことだと思います。(もし、そうでなければ単なる”ダメダメ組織”ですからね。) もちろん、「自組織に対して不利になりそうな穴を埋めていく。」という考え方も当然必要なものだと思います。(今の時代、性善説や理想論ばかり語るのは、完全な認識不足でしょうから。) 「信用・信頼」というのは、基本的には「後からついてくるもの」であって、日々の地道な努力こそがモノを言うものだと思いますし、そのためにも、当然サービスの安全性を確保すべきだとも思います。(まっとうな組織であれば。) 既述のブログ内でも、高木氏は「「安全なサイト」というのは、サイト自体のセキュリティー的な強度云々ということではなく、”利用者自身の安全”を確保できるサイトという意味である。→そのためにも技術の正しい理解が必要である。」という主旨の説明をされています。(もちろん、一文だけを捕らえて考察するのは危険であり、氏にはイロイロな含みを込めて書かれているのでしょうが。) SSL(PKI)の技術やその実装に関しても、「損得勘定」「リスクヘッジ」「責任」「サービス訴求」といった様々な目的を包含しているもの(またはそのように活用できるもの)という言い方もできるのではないでしょうか。 結局、何が言いたいのかというと、「このスレッドに書かれている事柄は、どの回答者のものも過不足無く全て重要であり、情報セキュリティーにかかわる以上、知っておくべき事柄であろう。」ということです。 以上、「有償の証明書の必要性」というご質問の内容(各論)から、いささか逸脱してしまった感もありますが、本補足を含め、何らかのヒントになれば嬉しく思います。 それでは。

nikuq
質問者

お礼

ありがとうございますm(__)m おっしゃる通り、皆さんのご意見全てが必要な事だと感じております。 もちろん、最終的に行った行動に対して責任を取るのは自分なので、どの様に解釈し行動しても、その結果は自分のモノだと思います。ただ、その結果をだす方法も、知っているのと知らないのでは大きく変わってくると思います。私自身、この様な質問をしたのも自分が考えた事に自信がないので質問して、皆さんの意見をお聞かせ頂き、自分なりの考えをまとめるためです。なので、Jzamrai様がおっしゃる通り、私からすると、書き込んで頂いた方全ての意見が大事だと思っております。実際、非常に参考になるご意見を頂いております。 皆様には心から感謝しております。 ありがとうございます!!m(__)m

関連するQ&A

  • SSLはどのページからスタートさせるか?

    ウェブサイトの暗号化技術SSLについての質問です。 ウェブサイトなどで、SSLを導入する場合、どのページからSSLのアドレス(httpsから始まるやつですね)にしたほうがいいのか、教えて下さい。 私の感覚としては、フォームを送る際に暗号化されていればいい、と思うので、例えば、IDとパスワードを入れるフォームがあるログインページでは、まだhttpでよくて、そのフォームが送る先からがhttpsなのかな、、と。 けれど、ほとんどのネット上のサービスで、ログインページからアドレスがhttpsになっているのを見ます。(このOKWaveでもログイン画面でもうhttpsになっていますよね。) 実際、ログインフォームの画面もhttpsにしておかないと、問題があるのでしょうか? 以上、よろしくお願いします。

  • FirefoxでSSL

    Firefox3.0.8を使っています。 例えば、Yahoo等に自分のIDでログインする際に、SSLページに移り、そこで自分のIDとパスを入力しますが、FirefoxだとこのSSLページにアクセスできません。 IE7も使っていますが、IEだとSSLページが開きます。 Firefoxオプションの詳細の中の暗号化タブを見ると「SSL3.0を使用する」と「TLS1.0を使用する」にチェックが入っています。 どうすれば良いでしょうか? よろしくお願いします。

  • 非SSLページからSSLページへの遷移時の暗号化

    SSLについて人によって意見がまちまちな問題が 浮上しており、困っております。 ぜひお詳しい方のお知恵をお借りできたらと思い投稿させていただきました。 非SSLページ(入力フォーム)→SSLページ(確認ページ) という単純な遷移です。 非SSLページは静的なhtmlファイルで 個人情報を入れてpostでsubmitするフォームになっています。 このとき、私の認識では、個人情報は暗号化されると 思っていました。 しかし、入力フォームもSSLページでなければ暗号化 されないという意見とそうでない意見が交錯しています。 遷移先がSSLであれば、証明書等チェックが入って 最終的にフォームの値含め、通信データは暗号化されて送信 されると思っていますが間違っているでしょうか? ちなみに個人情報を入れるページは心理的にはhttps であったほうがいいということは間違い無いと思います。 技術的な見地でお願いします。 よろしくお願いしますm(_ _)m

  • SSLは本当に安全ですか?

    ある番組を見て思ったのですが、日々技術は進歩し、以前は安全だったが今は安全ではないというものがたくさんあるようです。では、現在多く使われているSSLについてですが、VPNなどにも使われていますが、過去に解読されたことはあるのでしょうか?あったら大変なことだとは思いますが。 現在SSLより安全な暗号化あるのでしょうか。 SSLとSETは、どちらが信頼できるのでしょうか。 一つでもご存知の方おられましたら、教えていただけますでしょうか。 宜しくお願いします。

  • Apacheのユーザ認証について

    Apache1.3.*でBASIC認証をしようと考えているのですが、 2点わからない点があるので、わかる方教えてください。 (1)BASIC認証で入力するパスワードを暗号化するには? →認証をかけたいページをSSL暗号化していれば 認証のときも暗号化がかかる? (2)UNIXアカウントをそのまま認証に使用できない? 宜しくお願いします。

  • SSLについて

    会社のホームページ制作担当をしていますが、昨今個人情報保護法などのからみから、CGIフォームでのデータの送信にSSLでの暗号化をして欲しいという意見がでました。 現在使用しているホスティングサーバーはSSLに対応していないらしく、サーバーの乗換えを考えています。 いろいろ調べているのですが、共有SSLという安い方式と、5~6万円くらい金額がかかる、日本ベリサインなどのSSLサーバ証明書を取得する場合とがあるのですが、どう違うのでしょうか。 できれば安く上げたいのですが共有SSLだと何か問題が発生したりするのでしょうか。

  • SSL認証後のTracの動き

    現在、ローカルにあるTracを外部に公開しようと考えています。 SSLを使わないローカル接続ではエラーは出ないのですが、 一度、SSL通信を行った後にTracのログインリンクを押すと IDとパスワードを入力する画面が出ずに 「Authorization Required」となってしまいます。 これは、SSL通信の際に入力したIDとパスワードを 引き継いだままになっているから出るエラーなのでしょうか。 Tracの認証はダイジェスト認証に設定をしてあります。 別サイトでSSL認証 → 公開するTracのページ と言う流れです。 どなたかご教授願えないでしょうか。 よろしくお願い致します。 使用している環境は下記の通りです。 Software related with Apache and Subversion プロダクト ライセンス バージョン Apache2+SSL Apache License 2.0 2.2.6 mod_python Apache License 2.0 3.3.0b Subversion Apache License 2.0 1.4.5 Subversion Python Binding Apache License 2.0 win32-1.4.5_py25 Software related with Trac and Python プロダクト ライセンス バージョン trac-ja BSD License 0.10.4-ja-1 Python Python License 2.5.1 setuptools Python License or ZPL 0.6c7-py2.5 ClearSilver Neotonic ClearSilver License 0.10.4.win32-py2.5 SilverCity BSD License 0.9.7-win32-py2.4 SQLite3 Public Domain 3.3.8(+文字化け対応パッチ) SQLite Database Browser Public Domain 1.3 Apache Maven Apache Software License 2.0 2.0.8 Hudson Creative Commons Attribution Share-Alike license and MIT License 1.212 Tracのプラグインとして、TracWebAdmin、TracAccountManager、WebAdminUsers、IniAdmin、 AuthzWebAdmin、AddCommentMacro、TagsPlugin、TocMacro、TracNav、XMLRPCPlugin、 CustomFieldAdmin、DecoratorPugin、CompeteUserPlugin、TracWysiwygを含んでいます。

  • SSLにおまけをつける。

    規約では、 •Google は、SSL を使用して Google のサービスの多くを暗号化しています。 •お客様がお客様の Google アカウントへアクセスされる際、Google は、2 段階認証プロセスを提供し、Google Chrome ではセーフ ブラウジング機能を提供しています。 らしいのです。 GOOGLEさんもSSLでの暗号化に努力しているようですが、 おまけでもう少し自由に、手軽に暗号化できるようにはなりませんか? 例えば、Gメールを、日本発の暗号のカメリアでもう一回暗号化するとか... もちろん、本文を書いてから暗号化して、そのファイルを添付すれば良い事は理解できるのですが、 もう少し手軽にできないのでしょうか? 勝手に暗号化しても、規約違反にはならないと思っていますが、違反でしょうか?

  • SSLのページについて

    宜しくお願い致します。 SSL-IDを取得して、特定のページ(入力フォーム等)だけSSLで通信したい場合に、HTMLやPHP上でなにか指定する必要があるのでしょうか?SSLにしたくないファイルと同じフォルダにファイルをアップして、アドレスに『https』と入れるだけなのでしょうか?

  • 単一IPアドレスによる複数SSLの設定

    こんにちは。 はじめて投稿いたします。 単一IPアドレスによる、複数SSLの設定についてですが、通常はヘッダ部分が暗号化されてしまっているため、どの認証キーを使用すればよいかわからないので、単一IPアドレスによる複数SSLの設定はできないと思います。 しかし、最近SNI(Server Name Indication)という技術を知りました。 ただし、この技術はブラウザ依存があるため、XPのマシンで立ち上げたIEでは使用できないなどの問題があるようでした。 そのため、現在は複数IPアドレスを取得し、複数のSSLを設定している状況ですが、IPアドレスの払い出しには制限があるため、何か良い方法がないかと思っております。 SSLを設定しているサイトはコンシューマ向けのECサイトであるため、ブラウザの制限をかけるわけにもいきません。 もし、SNI以外の技術で解決できたり、SNIの技術+アルファでブラウザ制限をなくす技術があれば、と思い、投稿させていただきました。 OS:CentOS 5.6 Apache:2.2.3 OpenSSL:0.9.8f よろしくお願いいたします。