同じ問題を解決する相互TLSと証明書ピン留め？
アプリからMITMを防ぐために、証明書の固定を使用します。
承認されていない当事者が私のサーバーと通信するのを防ぐために、信頼できるソースからの通信を実際に受け入れるMutal TLSを使用できます。
何か不足しているのですか、それとも同じように聞こえますか？
相互TLSおよび証明書のピン留めはさまざまな問題を対象としていますが、アクティブなMITMを検出するという特定の問題を解決するためにも使用できます。ただし、相互TLSではMITMを検出するのはサーバーです（クライアント証明書は期待どおりではありません）。証明書のピン留めではクライアントです（サーバー証明書は期待どおりではありません）。
実装要件も異なります。
（サーバー）証明書のピン留めの場合、クライアントにはサーバー（またはCAピン留めの場合はCA）の証明書が必要です。証明書のフィンガープリント（ハッシュ）または公開鍵（より柔軟）でも十分です。また、すべてのクライアントは、サーバー証明書に関する同じ情報を共有できます。
クライアント証明書では、各クライアントに証明書と一致する秘密鍵が必要です。クライアント間で同じ秘密鍵を共有すると、攻撃者が鍵にアクセスする可能性が高くなるため、各クライアントは、異なる鍵を持つ異なる証明書を持っている必要があります。そしてもちろん、1つのクライアントからのキーが危険にさらされた場合に備えて、適切な失効と証明書を再発行するプロセスをインストールする必要があります。これにより、サーバー証明書のピン留めよりも複雑でスケーラビリティが低くなります。
つまり、サーバー証明書のピン留めとクライアント証明書の両方を使用してアクティブなMITMを検出できますが、サーバー証明書の使用ははるかに単純で、拡張性が高くなります。したがって、クライアント証明書を使用してMITMを検出することはおそらく悪い考えですが、いずれにしても必要な場合は、アクティブなMITMから保護するという副作用を使用できます。
クライアントが悪意のある手に渡ることが心配な場合は、証明書がまだ有効であるにもかかわらずペイロードが操作または盗用されるようにアプリをインストルメント化できることを考慮してください。
次の2つの異なるシナリオを検討してください。
相互TLSの証明書は引き続き有効であるが、データが操作されたり盗まれたりするようにアプリを計測するために、攻撃者はルート化されたデバイスを必要としません。これにはAPKの変更とこの変更されたAPKのインストールが含まれます。これは、偽造されたアプリを意識的に実行するエンドユーザー、またはそのようなアプリをインストールするように説得された誰かである可能性があります。さまざまな難読化手法を使用してそのような攻撃を困難にすることはできますが、断固として巧みなハッカーに対して完全な保護を提供する方法はありません。
ジェイルブレイクされたデバイスでは、悪意のあるアプリがトラフィックを乗っ取り、アプリを変更したり、有効なクライアント証明書を再利用（悪用）したりせずにMITM攻撃を効果的に実行できます。このような攻撃は、デバイスが所有者に知られていないジェイルブレイクされた場合でも発生する可能性があります。この状況では、ルートやインジェクションの検出、すべてのデータの暗号化を維持するなど、他のいくつかの保護etc。が攻撃を緩和または阻止するのに役立ちます。