2009-06-11 8 views
2

SSL接続(https)を介してWebサーバーと通信するクライアントプログラムがあります。この接続はどれくらい安全ですか?私は自分のWebサーバーにインストールされたSSL証明書を購入しました。私の理解は、クライアントとサーバーの間の中間者攻撃を試みても証明書がないということです。これは本当ですか?SSL証明書があってもSSL接続は安全ですか?

たとえば、ホスト名www.myserver.comを所有するIPにリダイレクトしようとすると、証明書がインストールされていない信頼できない送信元が接続で報告されるため、httpsは失敗します。


私のプログラムはバイナリであり、ユーザがブラウザで見られるウェブページではないことを指摘しておきたいと思います。したがって、単に「信頼できないSSLを受け入れる」と押し続けることはできません。私のバイナリは、信頼できないSSL接続が検出された場合に終了するようにコーディングされています。それを考えると、誰かが「中央にいる」人にトラフィックをどこかにリダイレクトし、暗号化されたデータを抽出することは可能ですか?

ありがとうございます!

答えて

7

'man-in-the-middle'が実際にクライアントコンピュータ(ウィルス、トロイの木馬、またはその他のマルウェアを考えている)の上にいる場合、その接続を介して行われていることをすべて読み取り/変更できます。ただし、クライアントとサーバーの間では、クライアントプログラムがSSL証明書の妥当性をチェックしていれば、接続は非常に安全です。

4

SSL証明書を受け入れるかどうかを選択する人物(コードではない)の場合、ホスト名が変更されたことによるエラーによって、その警告ボックスを直ちにクリックする可能性があるため、すべてを停止しないことがあります。

0

サーバーとクライアント間で転送されるデータは暗号化されます。

彼らは、彼らが自分のIPにホスト名www.myserver.com をリダイレクトするに しようとすると、接続が インストール 証明書のない信頼できないソースを報告しますので、したがって、たとえば、HTTPSは まだ失敗しますか?

はい。しかし、彼がセキュリティを心配していなければ、警告メッセージは無視されます。コミュニケーションだけが安全で安全です。受信したデータを解釈し、それが望むことをすることができるクライアントプログラム(ウィルス)がある場合。だからセキュリティ問題と "安全な" PCを持つことの重要性についてクライアント(ユーザー)を教育する方が良い。

非常に機密の場合にデータが転送された場合、ダイジェストフィールド(秘密鍵とともに転送されるデータで形成されます)を追加してクライアントに渡すことで、別のセキュリティレイヤーを追加できます。クライアントは、ダイジェストをもう一度作成し(受信したデータと秘密鍵を使用して)、不一致を比較します。

不一致がある場合、データは転送中に変更されました。

3

これは、クライアント側で証明書を検証する方法と、検証プロセスで信頼するように選択したCAによって異なります。

クライアントアプリケーションが信頼するいずれかのCAが同じホスト名に証明書を発行した場合、この証明書はMITM攻撃で使用できます。 (それは人々が"wrong"人にその証明書を発行していることを完全に知らされていません)。

シグニチャが有効かどうかを判断するためにどのCAが使用されているかは、SSLライブラリと使用方法によって異なります。

I.e.ブラウザの場合、firefoxは、ブラウザが信頼する多かれ少なかれ評判の良いSSLベンダーのCA証明書のセットとバンドルされています。

Windowsには、IEがデフォルトで信頼する証明書ストアがあり、Microsoft SSLを使用して他のアプリケーションを推測しています.Libraraiesには、この証明書ストアを使用するか既定で使用するオプションがあります。

0

あなたが問題混乱している:

  1. SSLが提供するトランスポート・レベルのセキュリティを、。
  2. SSLにはないクライアント認証。

アプリケーションによっては、代わりにSSHトンネルのようなものを使用することを検討してください。これは、トランスポートを保護する強力な暗号化と、公開鍵暗号を使用したログイン資格証明の両方を提供します。

クライアントプログラムごとに新しい公開鍵を自動的に生成し、それを認証用の鍵リストに追加してログインすることができます。したがって、あなたが承認したクライアントだけがアクセスすることができます。

ほとんどのSSHクライアントは、既知のホストとは異なる公開鍵を持つサーバーに遭遇すると自動的に失敗します。これを独自のサーバー公開鍵になるように事前設定することができます。

3

はい、一般的に、SSLを使用している場合、MitMの攻撃から安全です。これは、SSLを防ぐために設計(改訂)されています。

SSL証明書は公開情報であり、秘密の価値はありません。あなたのサーバーは、Helloというクライアントにそれを渡します。それは秘密鍵で、証明書の公開鍵と一致していなければなりません。

接続の安全性を最大限に高めるには、クライアントに許容される証明書を厳密に制限する必要があります。実際には、証明書自体(または証明書のハッシュ)をクライアントに格納することによって完全一致に制限することもできます。その場合、ホスト名の照合にも気をつけません。また、敵意を持った仲介者があなたのホスト名を使ってCAから有効な証明書を取得し、DNSを破壊したというわずかな機会さえも排除します。

0

Tlsはハンドシェイクでクライアント認証を提供します