• ベストアンサー

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

宜しくお願い致します。 ここ最近、SSLについて触れる機会が多く色々と調べていたらちょっと気付いたのですが、SSLという暗号化技術そのものはApacheに後付け出来る機能なのだとわかりました。そうすると、高い年間費を払ってSSL-IDを取得する意味合いが良く分からなくなってきました。例えば、 『多くの人に見られるページはSSL-IDを取得し、管理など他の人間には見られないようなページはApacheに機能をつけるだけ』 という様な使い方の定義みたいな物があれば教えて下さい。金額的に安くないので、その差がはっきりと見えるとうれしのですが・・・

  • nikuq
  • お礼率75% (477/631)

質問者が選んだベストアンサー

  • ベストアンサー
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

その他の回答 (4)

  • suzui
  • ベストアンサー率67% (199/297)
回答No.5

保険料みたいなものと考えたらどうですか? 保険というのは自分が不幸になるほうにお金を賭ける一種のギャンブルですが、保険金が下りれば不幸が少しは相殺されますよね。でも保険に入っていたからといって幸せになるかはその人の生き方次第。保険が必要かどうかもその人の財布次第。 SSL-IDだって似たようなものです。 データを盗まれる、身元を詐称される可能性がある、と思っているから、お金をかけるわけです。現に、例えばベリサインでは、ベリサインの不始末で利用者が損害を受けたら一定限度内で損害を補填するようになっています。いまどき有償のSSL-IDはあたりまえ。それだけで信頼が買えるほどユーザはバカではないでしょう。有償のものを使っているからといって信頼や利益が得られるかどうかはコンテンツ次第。お金をかけるべきかどうかは、守るべきものの価値次第でしょう。 暗号化・認証を行わないことで利用者に損害を与える可能性があると思っていて、しかもその損害額が自分で負担できないと思ったら有償のSSL-IDを取得してください。 蛇足ですが、国や司法が証明書を発行すれば絶対安全かも、との書き込みがありましたが、それは国や司法が信頼でき、しかもやり方が正しい場合ですよね。私は懐疑的ですが。世の中から犯罪がなくなることはないし、国や司法は永遠不変ではないし。欠陥のないシステムをつくることはできないので。

nikuq
質問者

お礼

ありがとうございますm(__)m なるほどー。保険ですか。 そう考えると、非常に分かりやすいですね(^.^) もし個人情報が漏洩してて、その事に気付かず、利用者から、『おたくのサイトから住所が流出して、家に一人でいたうちのばあさんが詐欺にあったぞ!!どうすんだ!!!』なんてこと言われた日には、どう責任取ればいいか分からないですね(T_T)恐ろしい・・・ だからといって、SSL-ID取得してるから絶対安心!ではないんですね。現に、法律で人殺しちゃダメ!って言われてても、殺人はなくなりませんしね。いかに自分のリスクとクライアントの安全を守るかって事の一つのツールとして、SSL-IDや認証局があるって事ですね(^.^) ありがとうございましたーm(__)m

  • suzui
  • ベストアンサー率67% (199/297)
回答No.3

SSLと証明書について考えるときに、暗号化と認証という言葉が出てきますが、これは別の概念なので、区別して考えてください。意外とこれができていない人が多いので・・・ 暗号化は盗聴を防ぐためのもので、認証は、改ざん・成りすまし(およびその結果としての盗聴)・否認を防ぐためのものです。 暗号化なしで認証だけを行うことはありえますが(本人確認さえできればよく情報は秘密でもなんでもない場合)、認証なしで暗号化だけを行う行為はインターネット上のデータ交換においては無意味です。(だれだかわからない相手から秘密の情報を受け取っても仕方がない) SSLで使うサーバIDは、認証と暗号化の両方に使われ、不可欠な要素です。 それから、No.1さんのコメントについて補足というか、考慮が足りないと思われるのでコメントすると、 「第三者証明機関を利用するしないに明確な用途の違いがある訳ではないのだが、ありていに言うとブラウザに信用される事に金を払う価値があるかないかだな。」 「もちろん社内LAN内でイントラネットを構築するような場合は、LinuxやWindows Serverなどで自前で証明機関を立てればそいつが発行するルート証明書をクライアントにインストールして警告なしのSSL通信ができる。」 これは嘘ではありませんが、リスクの考慮が不足していると思います。その点はNo.2さんも明確にされていません。 「オレオレ証明書」を使うリスクについては、以下のページを参考にされてください。 無料でオレオレ証明書を使ったはいいが、あなたの管理が杜撰なせいでサーバIDが盗まれて、他人に損害を与えた場合は告訴される可能性があります。 社内で使った場合でも、管理が杜撰なせいで従業員や顧客の個人情報が洩れたらやはり告訴される可能性があります。 有償のサーバIDは、信頼されたいから使うというよりは、リスクを軽減させるために使うのです。 http://takagi-hiromitsu.jp/diary/20050123.html http://takagi-hiromitsu.jp/diary/20050205.html

nikuq
質問者

お礼

ありがとうございますm(__)m ルート証明書って相当重要なモノなんですね。 安易にインストールしてはならないモノだったんですね。。誰でも簡単に発行してしまっては、証明書としての意味合いが全くなくなってしまうんですね(-_-;) 思い切って国というか、司法が管理すれば絶対安心なんですがね。。車の車検見たく。。 なかなか難しい問題ですね(>_<) ありがとうございましたーm(__)m

noname#14035
noname#14035
回答No.2

こんばんは。 以下、少し回りくどい説明に感じられるかもしれませんが、できればお付き合いください。 >>SSLという暗号化技術そのものはApacheに後付け出来る機能なのだとわかりました。 ↓ もちろん、これは誤りではありませんが、少しポイントがズレた認識だと感じます。 SSLは、"PKI"と呼ばれる「公開鍵暗号方式を利用した通信インフラの枠組み」に含まれる一つの通信プロトコルであり、その技術や利用対象は、もう少し広い視野を持ったものです。(当然、"IIS"など他のWebサーバーでもSSL(サービス)は利用可能です。) Apacheは、基本構成をシンプルにして必要なサービス(モジュール)を後付していく設計思想をとっているため、多くのレクチャーがApacheへのSSLモジュール組み込みに関する解説を行っていると言うことです。 後述の内容を含め、SSLをより正確に理解し、正しく有効に活用していただくためにも、文末にて紹介のURLなどからたどれる「PKIやSSLについての基礎知識習得(概念理解)」をなさるように、私の方からはオススメさせてください。 全体的なイメージをつかむための流れとしては、「PKIの理解(公開鍵暗号や証明書の役割を含め)」→「それがSSLにどのように応用されているのかを理解」→「Webサイト(サーバー)への具体的なSSL実装・運用方法」というカンジになるかと思います。 >>高い年間費を払ってSSL-IDを取得する意味合いが良く分からなくなってきました。 ↓ SSLに関しては、どうしても「通信の暗号化」のみにイメージが集中しがちですが(ゆえに、証明書の重要性について直感的な理解がしにくいのですが)、もう一点大変重要なポイントとして、「認証」(通信相手が本当に意図した者であるか確認できる仕組み)という大切な要素を考えなければなりません。(ブラウザに表示される鍵アイコンの”中身”についての話です。) 想定されている(であろう)、<公開Webサイト(サーバー)>←→<不特定多数のクライアント(プラス、一部のページへのアクセス制限)>を想定したSSL導入については、「そのWebサイト(サーバー)にアクセスしてきたクライアントが、間違いなく本物のサイト(サーバー)に接続できていると(成りすましが無いことを)証明できる仕組み」が重要になります。(これが「通信の暗号化」を含めたSSLの屋台骨となります。) さらに具体的に言うと、「認証局(CA」と「証明書(この中にデジタルIDも含まれる)」の役割について理解する必要があります。 上記の要素について、nikuqさんがどの程度理解されているのかがわからないので、少々不安なのですが、そのサイトに初めてアクセスしてきた人を含めた不特定多数(商用サイトではお客)に対して、証明書を利用したサーバーの認証(身元保証)を行うためには、世の中のエンド・ユーザーが利用している(広く普及している)ブラウザにプリ・インストールされた”ルート証明書”(典型的にはベリサインのものなど)を利用できる環境をつくる必要があるわけです。 完全に閉じた組織であれば、無償で発行できる自前の証明書(いわゆる「オレオレ証明書」)を利用しても構わないという場合もありますが(ここのところ、国内の地方公共団体や国際的なオープンソース・ベースでの証明書利用環境も登場し始めていますが)、インターネット上の公開Webサーバーでは、上記のような有償の「ルート認証局からお墨付きを得た証明書」を利用するのが基本です。(仕組み上、信頼できる第三者に身元を保証してもらう必要があるという言い方もできるでしょう。) 商用サイトなど、不特定多数のお客(クライアント)のアクセスを前提としたサイト(サーバー)で自前の証明書を発行して運用した場合、アクセスしたクライアントのブラウザには「警告」(証明書の有効性=接続先のサーバの真偽を確認できない旨の)が表示されることになります。 ここで、その「オレオレ証明書」をクライアントのブラウザに「ルート証明書」としてインストールさせてしまえば、以後警告は出なくなるわけですが(その他の証明書の不備がある場合は別です。)、これでは「信頼できるルート証明書ありき」というPKI(SSL)の仕組み自体が台無しになってしまいます。(いまだに、このようなタブーを堂々と犯している組織(サイト)もあるのですが…) というわけで、インターネット上の公開サーバーで”大手をふって”SSLを運用したいのであれば、コスト比較の問題ではなく、有償の証明書を取得する必要がありますし、「クライアント側から見た動作検証」や「有効期限などの証明書管理(警告自体を出さない事が重要です。)」を含めた「正しい運用」を行う必要があります。 もちろん、自組織のみの運用や実験環境などであれば、上記の話は該当しませんし、自前発行の証明書利用も「正解」となるケースもあるでしょう。 しかしながら(しつこいようですが)、一般公開や商売目的でサービス提供を行うのであれば、既述のような鉄則を外すべきではありません。(逆説的に言えば、ルート認証局の商売(有償の証明書)が成立しているのには、やはりそれなりの理由があると言うことですネ。) 以上、あまり整理できていない記述で恐縮ですが、下記URLなどとともに参考になさってみてください。 それでは。 ■@IT ”PKI”をキーワードとしたレクチャーのリスト■ Copyright(c) 2000-2005 ITmedia Inc. ↓ http://www.atmarkit.co.jp/channel/pki/pki.html ■同 ”SSL”をキーワードとしたレクチャーのリスト■ ↓ http://www.atmarkit.co.jp/channel/ssl/ssl.html

nikuq
質問者

お礼

ありがとうございますm(__)m 詳しくご説明頂きありがとうございます! おっしゃる通り、本当に必要のないものなら、商売自体がなりたってないハズですね。。 PKIの概念も、ほんの一部のサギまがいのサイトがあるおかげで、利用者からすれば、全てのサイトに不信感が残りますし、その為に、健全に運営しているサイトは非常に迷惑を被っている可能性があります。PKIの骨組みを全てのサイトとユーザーが理解し、インフラとして当たり前の存在になると、こういった不安感は消え、サギまがいの一部悪質なサイトは消えて行き、安全なインターネットの環境が整うという事ですね(~o~)目先の事だけで判断していると、もっと大きな事に気付かないんですね(-_-;) 良く理解できました(^o^)丿 ありがとうございましたーm(__)m

  • anmochi
  • ベストアンサー率65% (1332/2045)
回答No.1

うむ、良い所に気づいた。 君の言うとおり、SSL通信そのものはOpenSSL+Apache+mod_sslで何の問題も無く行う事ができる。IISの場合も別途Windows Serverの証明機関を用意すればWindows 2000 Professionalでもできるし。 「じゃあVeriSignに払ってるあの金は何!?」という質問にずばり答えましょう。 「(SSL通信の直前に)ブラウザに警告が出てこないようにするために払うお金です」 SSL(https)の場合、基本的な構成では、クライアント(=ブラウザ)がWebサーバを信用する事が不可欠だ。とりあえずhttpsを使えるようにしてブラウザからつなげたら警告が出るだろう。あれはブラウザが自動で信用できないのでユーザに尋ねているわけだ。 ここでVeriSignの登場だ。 1.ブラウザはVeriSignを信用している 2.VeriSignは君のWebサーバを証明する ↓ 3.ブラウザは君のWebサーバを信用する という三段論法で君のWebサーバは信用される。するとブラウザは自分自身の判断で信用できるので警告が出ないわけだ。 ここで2番目にお金がかかるわけだな。君の想像通り、VeriSignに証明されようとされまいと君のWebサーバの暗号化力に違いが出るわけではない。 ちなみに1番目でブラウザはVeriSignをどうやって信用しているかというと、これが「ルート証明書」というもので、WindowsならたまにWindowsUpdateでも「ルート証明書のアップデート」というものが出てくるので更新されていっている様が分かるだろう。  第三者証明機関を利用するしないに明確な用途の違いがある訳ではないのだが、ありていに言うとブラウザに信用される事に金を払う価値があるかないかだな。  企業サイトでWebアプリ構築しといて警告が出てきたらイメージ悪いしそれは金を払うだろうね。対して趣味の自宅サーバで警告出てくるのはまぁ事前(トップページなど)にアナウンスして証明はしてもらう必要は無い事も多いだろう。  もちろん社内LAN内でイントラネットを構築するような場合は、LinuxやWindows Serverなどで自前で証明機関を立てればそいつが発行するルート証明書をクライアントにインストールして警告なしのSSL通信ができる。

nikuq
質問者

お礼

ありがとうございます! なるほどー。すごーく分かりやすいご説明、ありがとうございますm(__)m なんだか、そう聞くとお金払うのが腹立たしくなります(-_-メ)弱みに付け込まれているような気がして・・・(>_<) しかし、あのポップアップ警告はほんとにうざいので、不特定多数の人が見るようなサイトだと、即刻サイトから抜けちゃいますね。。。まあ、そう考えると信用料というか、サービス料みたいなものと考えて諦めるしかないのでしょうか・・・(-_-;) ありがとうございましたー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 よろしくお願いいたします。