6

私は、MITMがひどい結果をもたらす可能性のある企業サービスで利用可能な企業APIに取り組んでいます。

HTTPの代わりにHTTPSを使用することにしましたが、グーグルした後、SSLだけでは不十分であることがわかりました。

私が理解しているように、SSLの使用には2つの主な脆弱性があります:1)現在多くのCAプロバイダー企業が存在するため、クラッカーが通常の証明書を使用するMITM攻撃から誰も保護されていません(VeriSignと言われている記事をいくつか見つけましたVeriSignが世界で唯一のCAであったときに、MITMに秘密サービスを提供していた秘密部門がありました)2)ARPキャッシュポイズニングを使用している間、ほとんどのMITM攻撃が可能です

したがって、私は今のところ1つの解決策しか見ることができませんが、それがベストプラクティスであるかどうかはわかりません:APIは内部であるため、次のものを使用できます:1)対称暗号化アルゴリズムでデータを暗号化する2)使用できるIPを制限するAPI(アプリケーションの場合、サーバーファイアウォールの場合)

これで十分ですか?おそらく、MITMを不可能にする、本当に安全な接続を確立するための他のベストプラクティスがありますか?

このソリューション(SSL +対称暗号化アルゴリズム)で問題がない場合、この種の問題に最も適した暗号化アルゴリズムについてアドバイスをいただけますか?

事前に感謝します、どんな助け/アドバイスも喜んでいます。

UPD:VPN(frenchieによるアドバイス)はこのコンテキストには適していません

UPD2:公開鍵(RSAに類似)が可能です(thx 2 Craigy)が、サーバー側では非常に高価です。

4

3 に答える 3

6

HTTP の代わりに HTTPS を使用することにしましたが、Google で調べたところ、SSL だけでは不十分であることがわかりました。

あなたが何をググったかはわかりませんが、SSL/TLS を正しく使用すれば、MITM 攻撃からあなたを守ることができます。

このソリューション (SSL + 対称暗号化アルゴリズム) で問題がなければ、この種の問題に最も適した暗号化アルゴリズムを教えてください。

SSL/TLS での暗号化は、対称暗号化を使用して既に行われています。認証のみが非対称暗号化によって行われます。

私が理解しているように、SSL の使用中には 2 つの主な脆弱性があります。

  1. 現在、多くの CA プロバイダー企業が存在するため、通常の証明書がクラッカーによって使用される MITM 攻撃から誰も保護されていません (VeriSign には機密部門があり、MITM に機密サービスを提供していたという記事をいくつか見つけました。世界で唯一の CA) 2) ARP キャッシュ ポイズニングを使用している間、ほとんどの MITM 攻撃が可能です。

MITM 攻撃から保護することは、まさに証明書の目的です。(a) HTTPS が期待どおりに使用されていることを確認すること、および (b) サーバー証明書の有効性を確認することは、クライアントの責任です。

最初のポイントは明らかかもしれませんが、これはsslstripのようなツールが行う種類の攻撃です。それらは、ユーザーが HTTPS ページにまったくアクセスできないようにする MITM ダウングレード攻撃です。ユーザーとして、HTTPS である必要があるときに HTTPS ページにいることを確認してください。企業環境では、HTTPS を介してサーバーにアクセスしていることを確認する必要があることをユーザーに伝えてください。ユーザーだけが知ることができます (クライアント証明書認証も使用したくない場合)。

2 番目のポイント (証明書の検証) もクライアント次第ですが、そのほとんどはブラウザー内で自動化されています。ブラウザの警告を無視しないことは、ユーザーの責任です。残りの証明書の検証は、プリインストールされた CA 証明書 (Verisign など) を介して行われる傾向があります。

MITM 攻撃が (おそらく ARP ポイズニングを介して) 行われている場合、ユーザーは間違った証明書を取得する必要があり、続行しないでください。正しい HTTPS 検証により、安全な接続を確立するか、まったく接続しないようにする必要があります。

あなたが言及している脆弱性は、証明書の検証 (PKI モデル) に関係しています。実際、サーバー証明書が正しいことの確認は、ブラウザーが信頼する CA 証明書に依存します。そこでは、信頼できる CA は原則として任意のサーバーに証明書を発行できるため、このモデルはリストの中で最も弱い CA として適しています。信頼できる CA の 1 つがサイトの偽の証明書を発行し、それを別の関係者に渡すと、パスポート オフィスが本物の「偽の」パスポートを発行するのと同じことになります。対抗するのはかなりトリッキーですが、それを回避する方法があります。

  • 両方が信頼されていても、証明書の変更を監視するPerspective Projectsなどの拡張機能に頼ることができます。このような警告により、ユーザーは、証明書の変更が正当なもの (会社によって行われたもの) であったかどうかを調査するように促されます。

  • さらに根本的には、独自の CA を展開し、信頼できる CA 証明書をすべてユーザーのブラウザーから削除して、独自の CA 証明書のみをインストールすることもできます。この場合、ユーザーは、CA によって発行された証明書を持つマシンにのみ安全に接続できます。これは問題になる可能性があります (ブラウザが OS 証明書リポジトリを使用している場合のソフトウェア更新を含む)。

  • 原則として、証明書を完全に回避し、事前共有キー暗号スイートを使用できます。ただし、これはすべての SSL/TLS スタックでサポートされているわけではなく、必ずしも HTTP over TLS に適合しているわけではありません (私の知る限り、ホスト名の検証に関する仕様が不足しています)。

Security.SE に関する次の質問にも興味があるかもしれません。

于 2012-08-08T19:41:37.133 に答える
4

Man-in-the-middle攻撃から防御したい場合は、対称鍵暗号を使用することで、第三者によるデータの侵害を防ぐことができます。ただし、キーの配布の問題に直面します。これが、非対称キー暗号化が魅力的な理由の1つです。

ネットワークで非対称鍵暗号を使用しながらMITM攻撃から防御するために、独自の公開鍵インフラストラクチャを設定できます。認証局を設定および管理し、他のすべてを無効にして、だれも他人になりすますことができないようにして、MITM攻撃を防ぎます。CAが侵害された場合、MITM攻撃が再び発生する可能性があります。

同じページにいることを確認するために、これらの提案は実装に依存しません。最初の提案には、任意の対称鍵アルゴリズムを使用できます。

2番目の提案では、非対称暗号化または公開鍵暗号化と呼ばれる、より複雑なシステムが必要になります。これらはRSAのようなアルゴリズムに基づいて構築されています。

SSLは、鍵交換に公開鍵暗号を使用し、メッセージの送信に対称暗号を使用するプロトコルです。

于 2012-08-08T17:08:02.560 に答える
1

中間者攻撃を適切に防御するには、次の 2 つのことが必要です。

  • HTTP 経由で Web サイトを提供しないでください。HTTPS トラフィックのみをリッスンする
  • 有効期間が長い応答で Strict-Transport-Security ヘッダーを使用する

SSLStrip 攻撃による ARP ポイズニングは、ブラウザがサーバーとの HTTP 接続を開始し、後で HTTPS に移行することに依存しています。攻撃が有効になるのは、この移行ポイントです。

ただし、ブラウザーが要求を HTTPS 要求として開始する場合、ハンドシェークは他の処理が行われる前にブラウザーに対してサーバーを認証します。基本的に、中間者攻撃が行われている場合、SSL 接続を確立できなかったこと、またはサーバーが正しいサーバーではないことがユーザーに通知されます。

HTTP 経由で Web サイトを提供しないと、その Web サイトにリンクしているすべての人が、リンクで HTTPS を使用するように強制されます。Strict-Transport-Security ヘッダーは、HTTP を介してサーバーと通信しようとする試みを HTTPS に変換するよう準拠ブラウザに指示します。

あなたのユースケースでは、上記の2つの推奨事項以外のソリューションはやり過ぎのようです. Strict-Transport-Security の詳細については、 Strict-Transport-Security に関するウィキペディアの記事を参照してください。

于 2013-06-30T23:44:46.480 に答える