- - PR -
SSLでも「なりすまし」
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-01-25 18:18
暗号文や電子署名を第三者が入手して、それをもう一度送ることを「リプレイ攻撃」といいます。
SSL/TLSの場合、各パケットにシーケンス番号が暗号化されて入ってますので、同じパケットを2回サーバに送ってもサーバが攻撃を検出できます。 という説明がちゃんと書かれているSSLの説明文書って少ないですね。 | ||||||||||||
|
投稿日時: 2007-01-25 18:37
あなたが技術屋ではなく、素人が興味本位で調べているのであれば その程度の勉強でかまわないと思いますよ。 「SSLを評価する」と当初に仰っていますから、当然技術者として 質問されているのだと思っていました。 だとすれば、原理を理解した上でどういった攻撃の可能性があるかを踏まえ、 そして評価するのだろうと思って回答するわけですね。 技術者としてSSLを評価するのであれば当然それは仕事として やっているのでしょうから「それ以上勉強」するのが当然でしょうし、 それをしないで答えを得ようとするのであれば「無料で仕事を代行して」と いっているように聞こえてしまいます。 まぁ、このへんは誤解がすれ違いを生んでいることが多いので 安易に意思疎通をあきらめないのが吉です。 「非難がましい」と非難するのもまた「非難がましい」ので 感情的にならないでくださいませ。 | ||||||||||||
|
投稿日時: 2007-01-25 20:57
そう思うのは個人の自由だけど、思い込みで損をする事って多いよね。 ここは素人だろうが玄人だろうが関係なく、自分のわからない点を伝えることができている人の質問には回答付きやすいよ。
逆に考えよう。 「こんな程度」にしか説明がないんだから、その単語だけじゃ正確に伝わらないかもしれない。 正確に伝えたい時は前後の文章なども利用して正確になるように補ってあげないと。 そこを手抜いちゃったか、気が回らなかったから言いたいことが正確に伝わらなかったんじゃないかな。
いろいろ勉強。一生勉強。みんな前向きにいきましょう。 [ メッセージ編集済み 編集者: どせい 編集日時 2007-01-25 21:02 ] | ||||||||||||
|
投稿日時: 2007-01-25 21:53
読み返してみたら確かに皮肉っぽい表現でしたね。
用語の意味も大切だと思いますが、SSLについて質問するならTCP/IPの通信方式 程度は基礎知識として必要かと思います。 個人的には前のリプライが見当違いに思えたので、ついあんなコメントを付けて しまいました。この点はお詫びします。 このサイトには私のようなひねくれ者も多いですが、利用方法によっては非常に 有用です。 本編の方と併せて利用されるといいですよ。 | ||||||||||||
|
投稿日時: 2007-01-25 22:11
セッションハイジャックのことを言っているのかな。
あんまり私はネットワーク系は詳しくないので、 後半からの技術的な内容で間違ってたら指摘して欲しいのですが、 １．httpでトップ画面を開く ２．セッションIDが発行される ３．ブラウザにセッションIDが渡される この時点では通信を傍受可能ですよね。 で、 ４．httpsでログイン となったときに傍受しても中身は見れない。 でもセッションIDはhttp通信の時に傍受したからわかっている。 で、ブラウザのクエリにセッションIDを付加するとなりすましが出来る。 ログイン前に取得したセッションIDでは成りすましても、 ログインする為のパスワードやIDがわからないから、ログインすることが出来ない。 ログインしたあとであれば、ログイン状態で成りすましが出来る。 って事を懸念しているということですか？ 参考までに、私が対応した某サイトでは、 ログイン前はhttpですが、ログインはhttpsにしています。 これは当然な話ですが、ログインする前にセッションIDの付け替えを行っています。 そうすれば、傍受されていたセッションIDは無効になる為、 成りすましができないようになる。 ・・・という対策をしました。 ＃こんな対策じゃ意味ないよとか、指摘があれば宜しくお願いします。 | ||||||||||||
|
投稿日時: 2007-01-26 00:40
SSL 通信のシーケンスが分かれば疑問点が解決するのでは
ないかと思うので、参考になりそうなページを挙げてみます。 http://itpro.nikkeibp.co.jp/article/COLUMN/20060731/244715/ http://www.atmarkit.co.jp/fnetwork/rensai/cell05/ssl1.html 上の URL の「図3 SSL(TLS) のシーケンス」なんて、 公開鍵暗号を解っている人なら解り易いと思うのですが。 A さんになりすましてサーバと通信する為には (4) で生成した乱数を 入手しなければなりません。 (5) を復号化して乱数を得ようと、(2) でサーバの証明書ではなく なりすまし人の証明書を A さんに渡すと、 「図4 SSL(TLS) の仕組みがうまく働くためには事前にCAの公開鍵が必要」 のように、それがサーバの証明書では無いことがバレてしまいます。 | ||||||||||||
|
投稿日時: 2007-01-26 00:41
もうそろそろ、「SSLとやらは当然」として、「SSL」だと、何が出来るのか、 あるいは、何が出来ないのか、は広く知られた方がいいのかもしれませんね。 。 「成りすまし」に関して、「SSL」で出来ること。 -二者間通信(サーバ、とクライアント、とやらが存在せざる得ない) -「なりすまし」は、「サーバ」と「クライアント」のどちらで発生するかを 特定すれば、防止可能。正確には責任を相手に押し付けることで「成りすまし防止機能」が成り立つ。防止責任そのものは、各それぞれで逆になる。 「クライアント」がサーバの成りすましを防止する。防止しない場合は、 そのまま通信が成立する。 -サーバの公開鍵証明書による暗号化 --サーバの公開鍵証明書はある程度信頼する。程度は、信頼する認証局証明書 (べりサイン等)を信頼するかどうかに依存する -サーバのドメイン名はある程度信頼可能。サーバの公開鍵証明書にドメイン名(ex:example.com等)が書いてあるため。 -サーバの公開鍵証明書を信頼するのは必須。 -クライアント認証(クライアント認証が出来るような設定をサーバで行えば可能) クライアント認証は任意。してもしなくてもよい。 「SSL」で出来ないこと。 +三者間以上の通信(いわゆるエンドtoエンドだけ) +認証(「誰か」という特定は出来ない)サーバ、クライアントともに「SSL」の現状 実装では、不可能。 +現状確認(通信時に、サーバ、クライアントともに「今」存在するかどうかは不明。 証明書とやらは発行した時点では存在したかもしれないが、通信をした時点で その存在があるかどうかはSSLでは判定しない) +与信(通信できたからといって、相手は経済的には信頼できない。技術的には信頼 したければ信頼できる可能性は常に残ってはいる) | ||||||||||||
|
投稿日時: 2007-01-26 03:42
そうですね。「仕返し」のつもりで書きましたので非難そのものです。 本題と離れてしまいますが、やはり気は納まらないもので続けますと。 ２ページ目の最後まで私はそんな書き方をしてませんし、大半の方は「理解の不足」を指摘する内容に始終しています。 ある方など「基本的な理解の不足が原因のオレオレ推論の展開 」と言っておきながら、非難は思い込みと言い切ってますしね。 「正確になるように補ってあげないと」とはよく言ったものだと思います。素人には、自分の言葉が曖昧であるどうかすら知りようが無いにも関わらず・・・です。矛盾、欺瞞、屁理屈満点です。 セキュリティやサーバ・クライアントには素人でも、「日本人」として素人って訳でもありませんので。 ところで私が、 「上記ＵＲＬですらこんな程度なのに、それ以上勉強しなければ、ダメなようで。 」と言ったのは、甕星さんの書き込み (2007-01-25 15:57)に対してです。 リンクでもあるような一般的な使い方のはずをしている（それ以上の意味は無いということで）のに、さらに冗長な表現を求めるのか？ということです。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。