fiddler 2がHTTPS経由のすべての呼び出しを復号化できる場合、SSLのポイントは何ですか？

Question

Http要求呼び出しを非表示にして、アプリケーションでより安全にする方法についてしばらく前に質問しました。私は、人々がフィドラー2を使用して通話を確認し、自動応答をセットアップすることを望まなかった。誰もがSSLに行くように言われ、電話は隠され、情報は安全に保たれます。

SSL証明書を購入してインストールし、すべてをセットアップしました。 fiddler 2を起動し、https phpスクリプトだけでなくhttps Webサービスにも接続するテストアプリケーションを実行しました。

Fiddler 2は両方のリクエストを検出できるだけでなく、それらを解読することもできました！私はすべての情報が4番目と4番目に戻るのを見ることができました。

セキュリティにまったく違いがない場合、SSLを使用するポイントは何ですか。 SSLの有無にかかわらず、すべての情報が戻って4回目になり、自動応答を設定することができます。

.NETにSSL経由の通話を隠すために不足しているものはありますか？

[〜＃〜] edit [〜＃〜]

受け取ったいくつかの回答により、この質問に新しい部分を追加しています。アプリがWebサービスに接続してログインした場合はどうなりますか。アプリは、Webサービスにユーザー名とパスワードを送信します。次に、Webサービスは、良好なログインデータまたは不良を示すデータをアプリに送り返します。 SSLを使用する場合でも、fiddler 2を使用している人は自動応答を設定するだけで、アプリケーションは「クラック」されます。デバッグでデータを表示することがどのように役立つかは理解していますが、私の質問は、SSLが要求されたものに接続していることを確認するために正確に何をすべきかです。基本的に、中間者は存在できないと言っています。

Alexei Levenkov · Accepted Answer

これはここでカバーされます： http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp

Fiddler2は、HTTPインターセプトに対する「中間者」アプローチに依存しています。 Fiddler2はWebブラウザーに対して安全なWebサーバーであると主張し、Webサーバーに対してはFiddler2はWebブラウザーを模倣します。 Webサーバーのふりをするために、Fiddler2はHTTPS証明書を動的に生成します。

基本的に、Fiddlerが提供する証明書はすべて手動で信頼しますが、一致しないドメイン名の証明書を手動で受け入れる場合も同様です。

編集：Fiddler/man-in-the-middle攻撃を防ぐ方法があります-つまり、SSLを使用するカスタムアプリケーションでは、通信に特定の証明書を使用する必要があります。ブラウザの場合、証明書の不一致をユーザーに通知するUIがありますが、最終的にはそのような通信を許可します。

明示的な証明書の公開サンプルとして、Azureサービス（つまり、AzureのPowerShellツール）を使用して、Fiddlerでトラフィックをスニッフィングできます。明示的な証明書要件のために失敗します。

Andrew Cooper · Answer

サーバー側だけでなく、SSL認証のためにクライアント側の証明書を要求するようにWebサービスを設定できます。この方法では、Fiddlerはサービスに接続できません。必要な証明書を持つアプリケーションのみが接続できます。

もちろん、アプリ内で証明書を保護する方法に問題がありますが、とにかくユーザー名とパスワードに問題があります。アプリを本当にクラックしたい人は、Reflectorを試してみるか、クライアント側の証明書に関連付けられている秘密キーをメモリ検索することもできます。

この100％の防弾効果を実現する本当の方法はありません。これは、映画業界がDVDコンテンツを保護することと同じ問題です。 DVDを復号化してコンテンツを再生できるソフトウェアがある場合、そのソフトウェアの動作中に誰かがメモリダンプを行い、復号化キーを見つけることができます。

zaitsman · Answer

SSL/TLSの一般的なポイントは、Wiresharkを使用する盗聴者がペイロードを見ることができないようにすることです。 Fiddler/Burpは、システムと対話したことを意味します。はい、それは非常に単純な相互作用ですが、システムの1つが侵害される必要があります。

これらの基本レベルでこれらのMITMプログラムを役に立たなくしてセキュリティを強化する場合は、クライアント証明書認証（双方向SSL）が必要で、サーバー証明書とクライアント証明書の両方を固定します（たとえば、特定の証明書のみが有効であることを要求します） comms）。また、回線上で転送されるペイロードを各当事者の公開鍵で暗号化し、秘密鍵が所属するシステムにのみ存在することを確認します。この方法では、一方の当事者（ボブ）が危険にさらされても、攻撃者はボブがアリスに送信したものではなく、ボブに送信されたもののみを見ることができます。次に、暗号化されたペイロードを取得し、検証可能な証明書でデータに署名して、データが改ざんされていないことを確認します（最初に暗号化するか、最初に署名するかについては多くの議論があります）。さらに、sha2などのパスをいくつか使用して署名をハッシュし、署名が「送信済み」であることを確認できます（ただし、これは主に不明瞭な手順です）。

これにより、通信システムの1つを制御しなくても、セキュリティの面で合理的に達成可能な範囲で取得できます。

他の人が述べたように、攻撃者がシステムを制御すると、RAMを制御し、メモリ内のすべてのメソッド呼び出しを変更できます。