- ベストアンサー
SSLとプロクシについて
例えばネットバンキングなどで、間にプロクシを入れると、たとえＳＳＬ通信でも各種「鍵」が漏れてしまい危険な状態になると言われますが、では、 １．先ず、httpsプロトコルのページをプロクシ抜きで表示させる。 －－－－－－－－－－－－－－－－－－－－－－－－－－－－ 私の先入観ですが、この時点でクライアントとサーバーが「鍵」を 取得したというイメージなのですが．．． －－－－－－－－－－－－－－－－－－－－－－－－－－－－ ２．プロクシを設定する。 ３．パスワードなどを投入する。 ４．サーバーに送る。 の場合はどうでしょうか？ １の先入観は、まったくの想像で間違っているかもしれませんが、もし 正しいとすると、串には鍵がわからないので安全なような気もするのですが．．．？ これでもやっぱり危険なのでしょうか？ 宜しくお願いします。
- ネットワーク
- 回答数5
- ありがとう数15
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (4)
- wildcat-yp
- ベストアンサー率37% (303/813)
正しくSSLが運用されていれば多少悪意のあるプロクシやネットワークを介したところで情報が漏れることはありませんよ。 まれに中間者攻撃が可能となるセキュリティーホールが発見されますが、修正されていれば問題ありません。 どんなネットワーク管理者であってもとくにネットバンクのような厳密なSSLを使用しているサーバと、ウイルス等の感染されていないPCとの間できちんと認証された通信は盗聴できません。 後、公開鍵については暗号化されません。それは、公開鍵は暗号化しなくても情報漏えいされない仕組みがあります。詳しくは、公開鍵暗号方式の鍵交換という基本技術になりますので調べればすぐに見つかると思います。 もちろん、これらはあくまでも中間者攻撃を使用しない前提ですので、修正されていない不具合を利用した攻撃等は絶対にないわけではありませんが・・・
お礼
ありがとうございます。 返事が遅れてすみません。 「公開鍵暗号方式 鍵交換」で検索してみました。 よくわかりました。
- pakuti
- ベストアンサー率50% (317/631)
元のページの人が何を聞いてきて話をしたのかにもよりますが・・・ 一般的なProxyサーバーを利用してSSL通信をしているのであれば ログを見ても何をしているのかはわかりません。 それは、https://www.xxx.xxx/ （宛先）以降がすべて暗号化されて送られるためです。 もしもProxyサーバーが公開鍵暗号の中身を見れるのであれば 公開鍵暗号方式自体が何の役に立たない事になります。 但し、クライアントを欺く事で、Proxyサーバーが中間サーバーとなり Proxyサーバーと本来のWebサーバー間で暗号化、その認証情報を元に Proxyサーバーとクライアント間で暗号化 を行うのであれば 中身をすべて覗く事が出来ます。 アクセスを監視する等も目的でこのような製品を出している会社もいます。
お礼
ありがとうございます。 なるほど。 ＞アクセスを監視する等も目的でこのような製品を出している会社もい ＞ます。 悪意のある串なら、情報が漏れる可能性アリと言うことですね。 ところで、クライアントが公開鍵を受け取る時も暗号化されているので しょうか？ 公開鍵を受け取った後なら、 ＞https://www.xxx.xxx/ （宛先）以降がすべて暗号化されて送られる ＞ためです。 は、ボクにも理解できるのですが。。。 鍵自体が暗号化されているとして、鍵の復号をクライアントはどうやっ ているのでしょうか？
- pooh0206
- ベストアンサー率41% (179/433)
基本的にプロキシを間に入れても、鍵は漏れません。 SSLでは、最初に公開鍵暗号方式を利用するため、中間では解読不能です。 中間者攻撃があれば別ですが・・・
お礼
ありがとうございます。 http://www005.upp.so-net.ne.jp/nakagami/Memo/SSL/ http://www.atmarkit.co.jp/fsecurity/special/02fivemin/fivemin00.html を見て思ったのですが、 公開鍵を含む証明証の発行を受ける時に（タブン１の時）プロクシ が噛んでいるとマズイような気がするのですが。
プロキシの性質上、そもそも、httpsで一度成立したネットワーク通信の間に入り込むことはできません。ご質問の２が成り立たないことになります。
お礼
ありがとうございます。 http://oshiete1.goo.ne.jp/qa1989154.html と言う記事もあったりして、 いまいちスッキリしません。
補足
すみません、お礼の内容がトンチンカンになりました。 httpsは特別なルーティングを行っていて、串は間に入れないって ことでしょうか？
関連するQ&A
- プロクシに関する質問です。
プロクシに関して知りたいのですがＦｉｒｅｆｏｘを使っていますがネットで速くて安全なプロクシと検索して出てきたプロクシを刺すと自分のＰＣに入っている情報などもプロクシのサーバーの管理会社などに分かってしまうのでしょうか？ それとも単にプロクシを刺してどこぞこのサイトに行きましたと言う情報が知られるのでしょうか？ またプロクシを使うに当たってのに危険性とはどんな事でしょうか？ 危険なプロクシとはどんなプロクシで安全なプロクシとはどんなプロクシを指すのでしょうか？ 質問が多くてすみません。 詳しい方いらっしゃいましたら御説明よろしくお願い致します。
- ベストアンサー
- その他([技術者向] コンピューター)
- SSLについて デメリット
SSLについて デメリット ＷｅｂシステムのSSLはサーバーからクライアントのパソコン間の通信でデータを暗号化復号化して通信時のデータの安全性を図るものだと理解しています。 httpsで始まるURLの場合、全てのデータが暗号化復号化されていると理解しています。 これで正しいでしょうか。 では、安全性からしたら全てSSLにしたほうがよいと思います。そうなるとhttpで始まるＵＲＬはなくなるはずです。現実には多くのサイトがhttpで始っています。httpsにするメリットは安全性と思いますが、デメリットがあるのでしょうか。あればデメリットをお教えください。 また、「SSLサーバ証明書」はそのサイトが本物のサイトですという証明書であって、証明書がなくてもSSLにすることはできるという理解でよろしいでしょうか。
- ベストアンサー
- ネットワーク
- 「SSLプロトコルの検査機能」の安全性について
Q1.「ESET Smart Security8」の設定で「SSLプロトコルを常に検査する」をONにするとブラウザのURL欄の鍵印をクリックしてサーバ証明書を確認すると、発行者が「ESET SSL Filter CA」となっていますが、これは、Superfishの様に、勝手にサーバ証明書を発行していると云う事ですか？ ESET社が正規の認証局であっても、アプリで都度、サーバ証明書を発行するのは、Superfishi行為と云えるのでは？ 一方、「SSLプロトコルを検査しない」をONにすると、オルジナルの正規の「VeriSign社のサーバ証明書」が表示されます。 Q2.「ESET Smart Security8」の仕様では、「SSLプロトコルを常に検査する」場合は、検査対象の「サーバ証明書」は使用出来ないので、代替としてESET社の「サーバ証明書」を使用すると云う事ですか？ この仕様が非常に判り難く、納得がいかないのですが？ 検査対象の「サーバ証明書」が検査OKであれば、何故、オリジナル原本の「サーバ証明書」が使用出来ないのですか？ そもそも、ESET社の「サーバ証明書」は、当該サーバの安全性を保証・認証するものではないですよね？ あたかも、Superfishの様に、勝手にアプリ用の「サーバ証明書」を都度、発行して、オリジナル原本の「サーバ証明書」に上書きしている様にしか見えませんが？ Q3.Superfishの様に、「ESET Smart Security8」のESET社製「サーバ証明書」が、クラッカー犯罪者に抜き取られて、SSL通信が傍受・漏洩していると云う危険性はないのでしょうか？ 本件の安全性を立証するバックデータで説明頂けると助かります。 Q4.「SSLプロトコルを常に検査する」機能は、クラッカー犯罪者がSSLプロトコルでマルウェアをダウンロードさせる様な行為を防御する為ですよね？ この機能をOFFにすると「SSL通信では、一切、防御機能は働かずに、マルウェア等の被害を受けるリスクがある」と云う事ですか？ それとも、この機能は、「サーバ証明書」の真偽だけをチェックしているだけですか？ ※OKWaveより補足：「ESETセキュリティ ソフトウェア シリーズ」についての質問です。
- ベストアンサー
- ウィルス・マルウェア
- ssl接続エラー…
これまでこのような表示が出たことがなく、どうしていいのかわからないため、知恵を御貸しください。 インターネットに繋ごうとしたところ、 Ssl接続エラー サーバーとの安全な接続を確立出来ません。 サーバー側に問題があるか、サーバーが必要とするクライアント認証証明書を所持していない可能性があります。 エラーコード:ERR_PROTOCOL_ERROR と表示されます。 プロバイダはGoogleCrome セキュリティソフトとしてフリーソフトのアバストをインストールしています。 自分なりにスマホで調べてみましたが改善が出来なかったので… よろしくお願いいたします。
- ベストアンサー
- その他（インターネット接続・通信）
- SSLの公開鍵をCAから取得できる？
SSLの通信を確認しているのですが、 クライアントPCとサーバがSSLで通信する場合、公開鍵をサーバから クライアントPCは取得しているようですが、CAからは取得できないのでしょうか？ ブラウザにルート証明書がインストールされていないCAなら、 公開鍵をCAに要求し取得するものだと思っていましたが、 そうではないのでしょうか？ググっても明確な情報がでてきませんでした。ぜひご教示宜しくお願い致します。
- 締切済み
- その他（インターネット接続・通信）
- ＳＳＬの仕組みについて整理したい事
本を読んでると 色々用語が出て何か混乱してるのですが・・・ 単純に・・・と言うか要約すると サーバー側で秘密鍵・証明書を作って 証明書は信頼できるクライアントに配布して クライアントはそれなりソフトを開いて(例えばＳＳＬもできるＦＴＰソフト) 証明書を使ってアカウント入力し、データを送信 で、サーバー側で秘密鍵で開ける・・・って手順なんでしょうか？ 一つの本には単純に秘密鍵作成と証明書作成だけ書いてて もう一つの本は詳しく？掘り下げて サーバ証明書・サーバ公開鍵・サーバ秘密鍵・証明局公開鍵 とかあって、何だか判り辛いです・・・ サーバ証明書が公開鍵にあたるのかと思ってました (データの開け閉めに対して鍵はペアだから、やりとりするのに３つ以上も必要なんでしょうか？？？) ちなみに サーバ・ＣＥＮＴＯＳ ６ と クライアント・ＷＩＮＤＯＷＳ ７ でやってます イマイチイメージがしにくいです よろしくお願いします
- ベストアンサー
- その他（インターネット・Webサービス）
- SSLによる通信について
WWWにおける、公開鍵方式による暗号化について質問です。 SSLを使ったHPでは ブラウザ→サーバー 暗号化されている サーバー→ブラウザ ？？？ あるHPにおいてブラウザから個人情報を入力し、 サーバーに送信すると、SSLを使っている場合、 情報は暗号化されて送られますよね。 逆に、個人情報の変更などをする場合、サーバーに保存されてあった 個人情報が、クライアント側に送られてくるわけですが、 このときには情報は暗号化されているのでしょうか？ しくみまで詳しく分かっているかた教えてください。 おねがいいたします。
- ベストアンサー
- ネットワーク
- ＳＳＬの信頼性について
ネット販売の代金決済にＳＳＬによる暗号化通信があります。以前に知人がクレジットカードによるＳＳＬ決済でURLのプロトコルhttpsの確認、右下タスクトレイ上に鍵マーク確認、カギマークから発行元証明書の確認もしたようです。しかし結果して悪用されたそうです。その話を聞いて私はネット上のＳＳＬを信頼していません。下記についてご助言を頂きたいと思います。 （１）ブラウザで公開鍵で暗号化し、送信したデータが 通信経路上で秘密鍵が盗取されてデータが復元さ れ、情報盗取されることは可能でしょうか。 （２）証明書の発行元の偽装は簡単に行えるのでしょう か。 （３）発行元が本人(法人）であることは何で確認すれば 安全でしょうか。以上お願いいたします。
- ベストアンサー
- Windows XP
- ブラウザからのSSL通信の動きについて
【環境】 ・Windows XP SP2 ・Microsoft Internet Explorer 6 6.0.2900.2180 HTTPS接続において、client helloが送出されないと考えられる事象が発生しています。 HTTPサーバの遅延が発生した為、サーバに接続しているスイッチでサーバへの全パケットを取得したところ、HTTP接続のパケットは確認出来るが、その後のSSL接続のclient helloがクライアントより送付されない事象が確認できました。 HTTPサーバのログを確認すると、ほとんどのスレッドがSSL client hello待ちでWaitしている状態です。Wait中なので、遅延が発生している間、サーバCPUは、ほぼ0%の状態です。 サーバ側でSSL client helloがタイムアウトするまでWebサーバ遅延が持続する状況です。 通常、https://リンクをクリックした時点で、HTTPプロトコルのconnectが始まると同時に、SSL client helloパケットがクライアントから送付されると考えています。 送付されないのはブラウザのバグでしょうか？ Internet Explorer6のバグ情報を探ってみたが、該当すると思われる情報は見つけられませんでした。一般的なブラウザでこのようなバグが発覚せずに使われているのも信じがたいです。 【1】.一般的にクライアントのブラウザから、SSL client helloパケットが送付されるトリガーは何でしょうか。 （https://のアドレスをクリックする事かと考えてます。） 【2】.ブラウザの不具合によるSSLclient helloが送付されない事象をご存知ないでしょうか。 【3】.その他にSSLclient helloが送付されない原因として思い当たる事はないでしょうか 以上、よろしくお願いします。
- 締切済み
- ブラウザ
お礼
ありがとうございます。 私なりに、理解ができました。 １．ＳＳＬサーバは秘密鍵と公開鍵を作って、公開鍵をクライアントに 渡す。 ２．公開鍵で暗号化したデータは、秘密鍵でないと復号できないので、 公開鍵そのものを暗号化する必要はない。 ３．従って、proxy云々という話の次元ではない。 ４．ＳＳＬサーバは、認証機関に認証された証明書が発行されていて、 信頼性が保証されている。 ただし、 Ａ．古いブラウザやバグの混入によって、偽の証明書を見破られない 可能性がある。 Ｂ．悪意をもったproxyによって、偽のＳＳＬサーバに誘導される可能 性を否定できない。 （本来のＳＳＬサーバのページ構造が簡単なら簡単に－リアルタイ ムに－コピーできますよね。一々、アドレスバーをチェックして いられないし．．．） Ｃ．ＡとＢが複合した場合、かなりヤバイ。 ＞まぁ、proxyだけでなく、アクセス先のwebサーバにしても、 ＞無線LANアクセスポイントにしても、身元の知れないものを ＞使うのは非常に危険です。 納得しました。