web-dev-qa-db-ja.com

HTTPSのサーバー側で中間者を検出する

背景:HTTPSで動作するサイトがあります(HTTPはサポートされていません。HSTSを使用しています)。サードパーティのクラウドにデプロイされているため、サーバーハードウェアに対する制御とログ機能が制限されています。クライアント証明書認証の使用を強制することはできません。つまり、基本的には、標準の2要素認証(ログイン/パス+ SMS)を備えたパブリックHTTPSサイトであり、デスクトップまたはモバイルブラウザーからアクセスでき、ネイティブモバイルアプリ内から同じサイトに追加のAPIがあります。サーバーソフトウェアは.Net/IISに基づいています。

次のシナリオを検討しています-どういうわけかユーザーのコンピューター/スマートフォンは攻撃者の証明書を信頼するように作成されているため、従来のMiM攻撃が可能です(ユーザーは信頼できる証明書でプロキシに接続され、プロキシはサーバーに接続されています)。そのための一般的な(一部の国での)シナリオの1つは、インターネットプロバイダーがユーザーに自己署名証明書を信頼することを要求することです。

クライアント側のセキュリティを確保する(証明書の拇印などを確認する)-サーバー(つまり、アプリケーション)がMiM攻撃が行われていることを理解する方法はありますか?

これはこの質問のようなものです HTTPS-サーバーはクライアント側の証明書の詳細を見ることができますか? しかし、私はそのような攻撃をすぐに検出する方法だけを探しているわけではありません(可能な場合はもちろん良いでしょう)、ただし、ウェイについても同様です。これにより、たとえば、いくつかの履歴レコードを持つ長期実行でこのような攻撃を検出できます。

7
Lanorkin

完全な中間者攻撃はおそらく検出されませんが、通常これらの攻撃(またはファイアウォールでの合法的なSSLインターセプト)は完全ではありません。特にクライアントが提供する暗号については、ClientHelloを確認することをお勧めします。今日のブラウザでは、どの暗号が順序付けられ、どの順序が非常に一般的ですか。 Man in the Middleソリューションは通常、正確な暗号の複製を気にせず、独自の暗号セットを使用します。その他の機能は、プロトコルバージョン、またはSNIやALPNなどの特定の拡張機能の使用です。

通常、これらの機能の多くは通常のサーバー内から取得できないことに注意してください。つまり、通常、ほとんどの場合、最終的な暗号とプロトコルバージョンを取得します。さらに取得するには、TLSライブラリを計測するか、トラフィックをスニッフィングして後で分析する必要があります。

3
Steffen Ullrich