HTTP の代わりに HTTPS を使用することにしましたが、Google で調べたところ、SSL だけでは不十分であることがわかりました。
あなたが何をググったかはわかりませんが、SSL/TLS を正しく使用すれば、MITM 攻撃からあなたを守ることができます。
このソリューション (SSL + 対称暗号化アルゴリズム) で問題がなければ、この種の問題に最も適した暗号化アルゴリズムを教えてください。
SSL/TLS での暗号化は、対称暗号化を使用して既に行われています。認証のみが非対称暗号化によって行われます。
私が理解しているように、SSL の使用中には 2 つの主な脆弱性があります。
- 現在、多くの 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 に関する次の質問にも興味があるかもしれません。