- - PR -
SSLでも「なりすまし」
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-01-27 14:45
理解を促す理由は、成りすましが可能かどうかは、SSLを理解すれば分かるのだから 当然だ思いますが。
SSLの設計では、証明の確認は別で、確立とデータ通信のセキュリティ安全性は 同一です。確立時にデータ通信の暗号強度も一緒に定義するからです。
データ通信自体の完全性は保障しますが、データの意味内容は正しいかどうかは 分かりません。例えばセッションIDそのものをクライアント側 で偽造してたらSSLは正しいことを保障できません。 | ||||||||||||||||||||||||
|
投稿日時: 2007-01-28 14:17
人は理解できないから質問するのではないでしょうか。理解を促すのは賛成ですが、 「理解すれば分かる」では質問者への答えにはならないと思います。
何をおっしゃっているのか、理解できないです。
これとSSLにおけるなりすましの問題がどう関係するのか、理解できないです。 | ||||||||||||||||||||||||
|
投稿日時: 2007-01-28 16:27
こんにちは。
レスそのものケチをつけているだけではあまり意味がないと思います。もちろん私も含めて。 今回のスレ主様は、基本的な理解など不要だが、自分の漠然とした質問には簡潔に答えて欲しいという要望をお持ちの方だと見うけられます。 しかも、どこかの記事を斜め読みして不安を感じたと思われる程度の、漠然とした質問を連発していらっしゃった。 これでは、理解を促されて当然だと感じますね。 通信やセキュリティの基礎知識・用語が不十分、かつ、基本を理解する気のない方に対してSSLに関係する説明をするのは困難だと思います。 スレ主様の問いに対して他の方がレスをつけた。その内容に対して不満があるのでしたら代わりにご自身の持つ正確な内容を補足してあげるのも一つの方法だと思います。 それなりの精度の知識を持っていらっしゃることは、blunder様の最初のレスから窺い知れますから。
| ||||||||||||||||||||||||
|
投稿日時: 2007-01-28 19:10
いえ、ケチをつけているのではなく、ただわかるように説明してほしいだけです。質問者 には質問の意味を明確にするよう要求しているのですから、回答者も回答の意味を明確に すべきではありませんか。でないと一方的にすぎませんか。 質問者の質問の意味はおそらくハンドシェーク時には認証をしていても、その後のデータ 通信時には認証の効果が持続しているのかどうかが定かではない、ということではない かと思います。ハンドシェーク時の認証は1回きりのもので、データ通信時にはその効果 がなくなっていて、第三者が通信に割り込めるのではないか。あるいはデータ通信時に も毎回認証が必要なのではないか。 この疑問に答えるには １）ハンドシェーク時には当事者以外が鍵交換に関与できないようになっていること その結果鍵情報は当事者間だけの秘密になっていること ２）ハンドシェーク時の認証、鍵交換の結果は、ハンドシェーク終了後もセッション継続中は持続的に保持されること（クライアント、サーバの内部状態として） またこれを第三者が推測することはものすごーく困難なこと ３）各データブロックの送信のたびにMAC値の検証が行なわれること MAC鍵は当事者間だけの秘密なので、これが一種の認証の働きをすること を説明すればよいように思います。 こういったことを言えば、認証の結果が持続的に効果を発揮していて、第三者が割り込 む余地がないことをわかってもらえるのではないかと思います。 あと、ついでにいうと、鍵情報を持たない第三者は通信の傍受はできても、通信に参加 （送信）はできないことや、暗号文を入手してもそれをそのまま送ったのでは通常はNG で、いったん平文に戻してから、再度暗号化しなければならないことも言ったほうが いいかも。もし暗号文を入手してそのまま送るだけというなら、単なるデータの中継し かできず、なりすましはできないこと。もしかしたらそのレベルの理解が疑わしいのか もしれません。 そう思ったんですが、どうなんでしょうね。説明するの大変です。 | ||||||||||||||||||||||||
|
投稿日時: 2007-01-29 00:12
はからずもさんの最初の質問はパスワード認証に関する質問だったんですよね。です から直接SSL認証に関係した質問ではなかったんです。だからSSLの仕組みを理解しろと いわれることが分からなかったんでしょう。しかしSSLで保護された通信チャネルには 第三者が割り込めないことが、だんだん理解できてきたということなんだろうと思い ます。SSLチャネルを傍受してID、パスワードを入手したとしても、それだけではなり すましはできない。どうもそういうことらしいな、と。
たぶんそれぞれが別の暗号技術（個別の暗号技術）という意味なんだろうと思います。 たぶん盲点になっているのはSSLにレコード層が存在しているということで、レコード層 を通じてそれぞれがつながり合っているということになるんだろうと思います。なぜな らハンドシェーク層もアプリケーションデータ層も全部レコード層の上に乗っかって いるので、レコード層を通じてつながり合っていると考えられるからです。そこが 見えていないために、それぞれがばらばらに存在しているだけのように見えていて、 連携の仕方が見えてないのではないかと思います。でも説明するのは大変ですね。
質問者の観点からは、SSL通信チャネルへの割り込み（なりすまし）はできないらしい ことは何となくわかったが、その根拠がわからないということじゃないかと思います。 これは回答者の方々も、なぜなりすましができないかの根拠を明示していないからで はないかと思います。それは私自身も同じで、私自身もどちらかといえば質問者に近い 観点でこのスレッドを眺めています。ですのでなりすましができない根拠が知りたい です。そのためにこのスレッドを見ているようなものですから。 | ||||||||||||||||||||||||
|
投稿日時: 2007-01-29 00:27
こんばんは。直前の blunder さんのコメントに関して。
質問の内容なり質問者の背景がある程度明確化されてなければ、回答しようがない、もしくは的外れであることを覚悟した精度の不確かな回答しかできないため、質問と回答はそもそも対等ではないと考えますが…。 一方的と判断されたのは何故でしょうか?
「そもそも質問者は『鍵交換』という概念の存在すら頭になかった」に10ペリカ。
質問者自身は参考サイト等で既に情報収集をしていて、それであの理解度な訳ですから。的確に要点を突いた説明ならば納得させられるか、というと分の悪い賭けだと思いますけどね。 止めはしませんが、大変なのは確かでしょう。回答者がそこまでの労力を負う義務は無いと考えます。 そもそも、この意見というのは、「SSLの基礎を先に学べ」と根本的に違いはないのではないでしょうか? 「参考サイトなりを見て勉強しろ」か「オレの説明を見て勉強しろ」かの違いでしかない。 もし仮に、「勉強したいが分からない」という質問であれば、「勉強しろ」のみの回答は不親切とも言えるかも知れませんが、今回は質問者自体が、事前に何らかの想定をした上で「問題があるのではないか」と話を振っている訳ですから、その背景がないとお話にならない。その背景すらも満足に説明できないようでは、打つ手はないでしょうね。 「勉強しろ」という回答は、「この件を考えるに必要な前提知識が無い」ことを宣告するもの。例えば、九九ができない子供に分数計算をいきなり説明する方はおりますまい。同じことだと思います。 ※今までの遣り取りを読み返すに、スフレさんの回答が最も質問者の意図に沿っているように感じますが、それであっても、前提知識が欠如している状態ではどれほどの効果があったのか…。 | ||||||||||||||||||||||||
|
投稿日時: 2007-01-29 10:59
angelさんのご指摘で気づきましたが、他の方に無意味な努力を求めるような言い方を
してしまっていました。ごめんなさい。
質問と回答は対等と考えていたので、そう言ってしまいました。今そうでないことが 理解できました。
はい、おっしゃる通りですね。皆さんに過大な労力や義務を押しつけるような言い方を したことをお詫びします。また自分でも何をやろうとしていたのかと空しくなってきま した。
「勉強しろ」ではなく、「自分の恥ずかしい考えやオレオレ推論を人前にさらしながら 一緒に考えてみる」という感じのスタンスでとらえていました。こっちも（本来は人前 では言いたくない）恥ずかしい考えを見せるのだから、そっちも手の内を見せてよ、と いう感じでした。ですので参考サイトを示すというのでは、ちょっとずるいというか、 そんな風に感じてしまったのです。しかし回答者の方の負担を考えると、ずるいなどと 非難してはいけませんでした。
おっしゃる意味通りですね。初心者へのサービスをするにしても、回答する方の負担 にならない範囲でのことだと思います。過剰なサービスは不必要ですし、それを要求す るような言い方をしたことは訂正、お詫びします。
もともとの質問からすれば、リプレイ攻撃くらいしか思いつきませんが、そもそも鍵を 知らなくてよいとする質問の前提が間違っているのだと思います。そこを変えれば、 もう少し意味のある質問になると思います。そこまで踏み込んで考えたほうが、たんに 質問者を突き放してしまうよりは、このスレ全体が面白くなるのではと思いました。 しかし今はそんなことをして何になるという感じで、ちょっと空しくなってしまいまし た。 もちろん私が無意味な努力をするのは私の勝手なのですが、それを皆さんに押し付ける ような態度はよくありませんでした。 では。 | ||||||||||||||||||||||||
|
投稿日時: 2007-01-29 22:22
。。。そうなんですか?私はまた、以下だと勝手に思ってました。 (1)質問者はSSLとやらを使えばすべてOKだと思った。 (2)あるとき「なりすましとやらにどうやって対応するの」とたずねられた (3)SSLだから大丈夫です、と答えた (4)どうして?と尋ねられて解答できなかった のだと思ってました。 SSLとセッションIDは、あまり関係ないのに言及したのはそのせいです。 ほとんどの場合、SSL+パスワード認証でなりすましをほぼなくせると いえばなくせます。なりすますためのパスワードを「盗聴」できない可能性が 高いからという理由です。 セッションIDの振り出しは、SSLと関係ないといえば関係がないので、 あえてパスワードを含めた「データの意味内容」はSSLでは保護しないと書いた までです。 例えばSSLサーバを構築したとして、パスワードがソーシャルハッキング でばれていた場合は、たとえSSLサーバであったとしても成りすましは 起こりえます。 という状況なのか、よく分からないので、前の回答になりました。 最近は多いと思ってるのですが、、、よく分からないけど「SSL」しとけばOKみたいな。 SSLだろうがなんだろうが、成りすましはありえます。自分で設計しない限り。 #SSLクライアント認証は、あえて無視しています(成りすまし防止は当然なので)
個別なのか。。一応PKIの範囲なはずなのだが、、「証明の確認」は、 私はX.509証明書検証を意図していたつもりでした。 SSLでは、SSLサーバのX.509公開鍵証明書(SSLサーバ証明書)をSSLクライアントに 送りつけます。 SSLサーバ証明書は二つ意味合いがあって。 (1)公開鍵にてプレマスターシークレットをクライアントで暗号化してサーバにて復号する。ついでにHMAC(ぢゃないけど)で完全性を保障する (2)SSLサーバ証明書の記述内容を検証(証明書検証 certification verify含む)する。 本来、証明書検証はクライアントが勝手にやる処理です。証明書のSubjectのCNに SSLサーバのFQDNを書く仕様も、後づけのような気がしますし。 #ここまでSSLサーバ証明書を無視するのなら、公開鍵だけ送りあうSSL仕様の方が #良かったのかな。。。と思わないでもありません。そんなものはありませんが。 とは言っていられないのでEVとかの規格が出てきたわけですが。 http://www.verisign.co.jp/server/products/ev_ssl.html http://www.itmedia.co.jp/news/articles/0611/08/news022.html SSLのレイヤーにRecordやAlertがあることは、SSLを実装する人ならともかく、 SSLを使いたいだけの人には、ほぼ無意味のような気がします。 ちなみに、SSLの「なりすまし」は、原理上クライアントとサーバの両方 ありえるのですが、質問者はどちらを意図したのでしょうね。 おそらくごちゃ混ぜになってると思いますが。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。