2

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

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


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

ありがとう!

4

7 に答える 7

7

「中間者」が実際にクライアント コンピューター (ウイルス、トロイの木馬、またはその他のマルウェアを考えてください) に常駐している場合、その接続を介して行われているすべてのものを読み取ったり変更したりできます。ただし、クライアント プログラムが SSL 証明書の有効性をチェックしていれば、クライアントとサーバー間の接続は非常に安全です。

于 2009-06-11T15:17:43.830 に答える
4

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

于 2009-06-11T15:12:06.137 に答える
3

はい、通常、SSL を使用すると、MitM 攻撃から保護されます。SSL は、それを防止するように設計 (および改訂) されています。

明確にするために、SSL証明書は公開情報であり、秘密の価値はありません. サーバーは、Hello と言うクライアントにそれを渡します。秘密にしておく必要があるのは、証明書の公開鍵と一致する秘密鍵です。

接続の安全性を最大限に高めるには、クライアントが受け入れる証明書を厳密に制限する必要があります。実際、クライアントに証明書自体 (または証明書のハッシュ) を保存することで、完全に一致するものに制限することもできます。その場合、ホスト名の一致についても気にしません。また、敵対的な仲介者が CA からホスト名を含む有効な証明書を取得することに成功し、DNS を破壊したというわずかな可能性も排除します。

于 2009-06-13T07:15:29.960 に答える
3

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

クライアント アプリケーションが信頼する CA のいずれかが同じホスト名に対して証明書を発行した場合、この証明書は MITM 攻撃で使用される可能性があります。(そして、証明書が「間違った」人々に発行されたということは、まったく前例のないことではありません)。

署名が有効かどうかを判断するプロセスでどの CA が使用されるかは、SSL ライブラリとその使用方法によって異なります。

つまり、ブラウザの場合、firefox には、お使いのブラウザがデフォルトで信頼する多かれ少なかれ評判の良い SSL ベンダーからの一連の CA 証明書がバンドルされています。

Windowsにも同様に、IEがデフォルトで信頼する証明書ストアがあり、MicrosoftのSSLライブラリを使用する他のアプリケーションには、この証明書ストアを使用するか、デフォルトで使用するオプションがあると思います。

于 2009-06-11T15:40:50.950 に答える
0

あなたは問題を混乱させています:

  1. SSL が提供するトランスポート レベルのセキュリティ。と
  2. クライアント認証。SSL にはありません。

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

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

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

于 2009-06-12T01:37:55.117 に答える
0

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

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

はい。ただし、ユーザーがセキュリティを心配していなければ、警告メッセージは無視できます。通信だけが安全で安全です。受信したデータを解釈し、必要なことを実行できるクライアント プログラム (ウイルス) が存在する場合。そのため、セキュリティの問題と「安全な」PC を持つことの重要性についてクライアント (ユーザー) を教育することをお勧めします。

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

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

于 2009-06-11T15:27:34.180 に答える
0

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

于 2013-03-29T16:04:04.617 に答える