- ベストアンサー
SSLの仕組みについて整理
- サーバー側で秘密鍵・証明書を作り、信頼できるクライアントに配布し、クライアントは証明書を使ってセキュアな通信を行う仕組みです。
- SSLはサーバ証明書・サーバ公開鍵・サーバ秘密鍵・証明局公開鍵といった要素で構成され、データの開け閉めには3つ以上の鍵が必要です。
- センセーショナルなタイトルではないですが、SSLの仕組みについての詳細を整理しています。
- hiroziro888
- お礼率72% (88/122)
- その他（インターネット・Webサービス）
- 回答数5
- ありがとう数7
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
ええと・・・これが分かりやすいかな？ http://dev.sbins.co.jp/cryptography/cryptography04.html >公開・秘密 で片方が暗号して、片方が複合できるなら >共通・秘密 でも同じ事の意味ですよね？ >（上文の流れで念の為の質問です・・・すみません） なんか混乱してますねえ。 「公開鍵暗号化方式」という時の「公開鍵」と、「公開鍵 暗号化方式」内で使う「公開鍵」は全然意味が違います。 上記は「暗号化・復号化の２つの鍵をセットで使う暗号化 方式」の意味ですし、後者は「公開鍵暗号化方式で、 他人に知られても良い方の鍵」の意味になります。 また「共通鍵」と言ってしまうと、「共通鍵暗号化方式」の 共通鍵を指してしまうので違ってきます。 用語が混乱してるんですが、何となく言いたいことは合って 居るような気がします。 >で、今回はＦＴＰサーバーでＳＳＬの話が出たので >今までＦＦＦＴＰを使ってて危険とあったので >今回は自宅サーバーで使おうと思いましたが >この場合は自分の家にサーバーもマイＰＣもあり自分で管理するので >承認局をわざわざ通す必要もないですよね？ なんか全然違う方に話が行ってる気がします。 SSL通信は「インターネットを経由してどこかにデータを送る」 場合に問題になる話なんですが・・・。 単にWebデータを自宅サーバーに送るなら、SSL云々なんて 全く関係ないですよ。だって「転送経路がネット上に公開 されているわけじゃない」ですもん。LANケーブルで転送 すればＯ．Ｋ．。暗号化なんぞ不要です。 自宅サーバー関連でSSLが必要なのは、「他人が、あなたの 自宅サーバーとの間で秘密の通信をしたい場合」だけです。
その他の回答 (4)
- hs001120
- ベストアンサー率60% (473/788)
>調べてみると公共機関とかがやってたんですね >政府もやってたんですね 公共機関・政府以外もありますよ。というか大多数は民間です。 ただ、民間にしてもそのセキュリティ管理と信用が厳しく問われます。 >第三者が信用されたところで >そこに送信元は登録しておけば >クライアント側は、ブラウザ等で受け取り・確認 端的に言えばそうです。 ちなみに今年(2011)は、その信用が問われるニュースが飛び交いました。 http://jp.globalsign.com/information/important/2011/09/370.html http://www.atmarkit.co.jp/news/201109/08/diginotar.html http://internet.watch.impress.co.jp/docs/news/20110926_479659.html DigiNotarが破綻した事によって、そこに第三者証明をして貰っていた サイトのSSL用証明書は将棋倒しに、有効な第三者証明のない怪しい証明書扱い となり、かなり大きな影響がありました。
お礼
判りやすい解説だけでなく その他の事例やその記事が為になります！ 有難う御座いました！
補足
なるほど、判りました！ 今は個人単位での運用を目指しているので ここを使わないかも知れませんが 物凄く勉強になりました！ また、レクチャーとしての記事の物凄く助かります！ これらへの対処法も勉強しないといけませんね！
- FEX2053
- ベストアンサー率37% (7991/21370)
>初心者なので、コンガラがってて >一応確認したいのですが いえいえ、私も理解するまでに結構時間がかかりました。 >だから共通鍵は使い捨てに向いてて中の方で使い >外側は解析されにくい公開鍵で・・・ですよね？ まあ、そう思っても良いかと。 >秘密鍵は複合化 >公開・共通鍵は暗号化と思ってたのですが >逆の設定もできるのでしょうか？ 逆だって可能です。 要は鍵が２セットあって、片方で暗号化したものは、 もう片方でしか開けないということなんです。たまたま 「公開する方」を公開鍵と言ってるだけで・・・。 >後にある証明局は認証局でよろしいですよね？ ハイその通り。すいません間違えて。 この辺は#2さんの方がうまく説明してくれてますから、 そちらも参考に。 >１ >公開鍵で覆った >中身は共通鍵の暗号化データ > >２ >公開鍵で覆った認証局 ・・・の「データ」ですね。基本はそれでオッケーです。 証明してもらうサーバーは、「所定の書式で内容を書いた データ」を認証局に送ります。認証局はそのデータを 秘密鍵で暗号化してサーバーに送り返します。 サーバーは、通信開始時にこの「秘密鍵で暗号化した データ」をそのまま添付してクライアントに送ります。 暗号化したデータは「i.e.などの中に既に存在する 公開鍵」で復号化は簡単にできますが、同じデータを 「秘密鍵」を使って暗号化することが出来ません。 認証データの秘密鍵は「認証局」にしか存在しませんし、 そもそも、認証データは「ハッシュ化」という特殊な方法で 暗号化（長い文章を特定の方法で短くする、Yahooの 地図のURLなんかがその方法で短くなってる）してるので 簡単には「内容を確認する」ことすらできないんです。
お礼
色々な解説と 知らなかった事実が判りました！ 有難う御座います！
補足
＞逆だって可能です。 ＞要は鍵が２セットあって、片方で暗号化したものは、 ＞もう片方でしか開けないということなんです。たまたま ＞「公開する方」を公開鍵と言ってるだけで・・・。 ← え！？ 初めて知りました！ 確かに本やサイト等で調べても 必ず送るほうが公開・共通鍵側で説明し 複合を秘密鍵・・・ でしか説明してませんし 逆の事には触れませんね・・・新事実でびっくりです(驚) チキンですみませんが確認の質問です 公開・秘密 で片方が暗号して、片方が複合できるなら 共通・秘密 でも同じ事の意味ですよね？ （上文の流れで念の為の質問です・・・すみません） で、今回はＦＴＰサーバーでＳＳＬの話が出たので 今までＦＦＦＴＰを使ってて危険とあったので 今回は自宅サーバーで使おうと思いましたが この場合は自分の家にサーバーもマイＰＣもあり自分で管理するので 承認局をわざわざ通す必要もないですよね？
- hs001120
- ベストアンサー率60% (473/788)
>サーバ証明書が公開鍵にあたるのかと思ってました 単に公開鍵というだけでは、公開用の鍵情報というだけに過ぎません、 それを誰かが証明してくれているかは別の話です。 秘密鍵・公開鍵それ自体は生成可能なフリーソフトで、誰でも簡単に生成できます。 例えば私が"出鱈目銀行"のページを作り、秘密鍵&公開鍵を生成することは簡単にできます。 そんなものを信用してお金の振込みとか出来てしまってはマズイですよね。 "出鱈目銀行"が現実に存在する企業で、その公開鍵は"出鱈目銀行"の公開鍵に間違いなく、 誰かが勝手に"出鱈目銀行"を騙って公開鍵を提示しているわけではない。 ということを証明できる事が必要です。 それを第三者認証局が証明してくれてはじめて、信用して良いものになります。 公開鍵証明書 http://www.atmarkit.co.jp/aig/02security/pkeycert.html
お礼
詳しい解説、有難う御座います！
補足
この証明局ってそもそも何だろ？ と思いました 調べてみると公共機関とかがやってたんですね 政府もやってたんですね 第三者が信用されたところで そこに送信元は登録しておけば クライアント側は、ブラウザ等で受け取り・確認 できるって解釈でよろしいでしょうか？
- FEX2053
- ベストアンサー率37% (7991/21370)
まず、SSLの仕組みを知る前に、暗号化の一般的な 知識を整理した方が良いです。 http://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7 暗号化処理は「共通鍵暗号」の方が、計算が速く簡単 なんですが、共通鍵を長く使ってると暗号が解析され 易いうえ、「鍵の受け渡し」を秘密に行わないといけない という問題があります。 一方、公開鍵暗号は暗号の解析がしにくく、公開鍵は 公開しちゃって大丈夫、というメリットがありますが、 何せ計算が非常に大変で処理が重いという問題が あります。 SSLはこの２つの暗号化方式の「いいとこどり」をした 通信方法です。要は「共通鍵を公開鍵暗号で送る」ん ですね。これなら共通鍵は毎回使い捨てでもオッケー、 面倒な公開鍵暗号の復号化も量が少なくて済みます。 ここまでの前提を了解したうえで。 まずは、SSL通信をしたいサーバーは、公開鍵を用意 しておきます。クライアントは通信開始時にその公開鍵 を受け取って、通信開始の準備をします。 で、サーバー側から「サーバーの持っている秘密鍵」で 暗号化した信号をクライアント側に送ります。クライアントは 公開鍵で複合化します。そうすると、その中から共通鍵が 出てくる、という寸法ですね。 問題はその「公開鍵」「共通鍵を送る信号」が、 本当にそのサーバーから送られているかの保証です。 認証局はそのために存在します。認証局は事前に クライアントに「その証明局の証明書」送ります（i.e.などは 事前に主要な証明局の証明を受け取ってます）。 あとは、先ほどの「サーバーからの共通鍵の送信」と 同時に証明局の特定の証明書を秘密鍵で暗号化した ものと、その証明書の公開鍵を送付します。 こうすれば、その「証明書が同じものか」はクライアントで 照合でき、秘密鍵は証明局しか持ってないので、 発信元も確認できるという寸法です。
お礼
色々為になる解説、有難うございます！
補足
何となくイメージはわいたかも？ 前半の前置きは結構理解できました！ 共通鍵は軽いけど解析され易い・・・ 公開鍵は解析されにくいが重い・・・ だから共通鍵は使い捨てに向いてて 中の方で使い 外側は解析されにくい公開鍵で・・・ですよね？ ＝＝＝ 初心者なので、コンガラがってて 一応確認したいのですが ＞で、サーバー側から ＞「サーバーの持っている秘密鍵」で ←１ ＞暗号化した信号を ← １ ＞クライアント側に送ります ＞クライアントは公開鍵で複合化します ←２ ＞そうすると、その中から共通鍵が ＞出てくる、という寸法ですね。 １と２って逆だと思ってました 秘密鍵は複合化 公開・共通鍵は暗号化と思ってたのですが 逆の設定もできるのでしょうか？ それとも、自分の考えてる事が間違いなのでしょうか？ ＞『 認証局 』はそのために存在します。認証局は事前に ＞クライアントに「その証明局の証明書」送ります（i.e.などは ＞事前に主要な証明局の証明を受け取ってます）。 ＞あとは、先ほどの「サーバーからの共通鍵の送信」と ＞同時に証明局の特定の証明書を秘密鍵で暗号化した ＞ものと、その証明書の公開鍵を送付します。 後にある証明局は認証局でよろしいですよね？ 話を整理すると サーバから送るのは １ 公開鍵で覆った 中身は共通鍵の暗号化データ ２ 公開鍵で覆った認証局 この二つを送って クライアントは公開鍵で２つ複合し 証明書で、送信元の信頼を確認後 共通鍵の複合で中身のデータを受け取る って事でしょうか？
お礼
素人の為に、長々と説明し 誤解を与える解釈もありました すみませんでした！ 最後まで付き合って頂き とても感謝します！有難う御座いました！
補足
すいません！ 共通鍵の意味自体、また履き違えてました！ 一つの鍵と、ペアの鍵自体の意味と 方式(やり方・手段)の意味をごっちゃになってしまいました >>で、今回はＦＴＰサーバーでＳＳＬの話が出たので >>今までＦＦＦＴＰを使ってて危険とあったので これもすみません！ 書き方が悪かったです！ 自分の事情の話なのに 話の流れみたいな言い方して誤解を与えてしまいました！ ＬＡＮ内とは言え、セキュリティを徹底的に勉強しようかと思い その一つのＳＳＬについても勉強しようと思ってました・・・ 今回の件について、せっかくここまでやったので 後は自分でＣＥＮＴＯＳで実験してやってみます！