クライアント証明書はMITMに対する保護を提供しますか？
VPNやToRを使用せずにMITM攻撃からクライアントを保護する方法を探しています。私の考えでは、クライアント証明書mightで十分ですが、この領域ではサーバーまたはブラウザのサポートがあまり拡張されていないため、完全にはわかりません。
クライアント証明書がMITM保護を提供するかどうか誰かに教えてもらえますか？
その保護は認証交換のためだけですか、それともTLSセッション全体を保護しますか？
これを詳細に研究するための優れたリソースはありますか？
中間者攻撃 は、攻撃者がクライアントとサーバーの間に自分自身を挿入し、サーバーと通信するときにクライアントを偽装し、クライアントと通信するときにサーバーを偽装する場合です。 「なりすまし」は、期待されるピアアイデンティティがある限りにおいてのみ意味がありますis匿名クライアントを偽装することはできません。
サーバーの観点から、クライアントが証明書を表示し、CertificateVerifyメッセージの一部として彼の秘密鍵を使用する場合（- SSL/TLS標準 、セクション7.4.8）。サーバーは、悪意のある、または無能なルートCAを含まないトラストアンカーのセットに関してクライアント証明書を検証し、サーバーは、適切なクライアント（クライアント証明書で識別されるクライアント）と通信しています。保証は、接続内の後続のすべてのデータに対して保持されます（[〜＃〜] not [〜＃〜]は、クライアントが証明書を示したハンドシェイクの前に交換されたデータに拡張されます「再交渉」でした）。
これは、クライアント証明書が実際にclientトラストストアに挿入された不正なCAの特定のシナリオから保護されることを意味します。そのシナリオでは、「攻撃者」は、攻撃者が制御する特定のルートCAをクライアントに信頼させることに成功し、攻撃者がターゲットサーバーの偽の証明書をオンザフライで作成してMitM攻撃を実行できるようにしました（これは正確に一部の組織で展開されている一部の「SSLコンテンツフィルタリング」プロキシで何が起こるか）。クライアントがCertificateVerifyメッセージの一部として署名するのは、サーバー証明書を含む多くのデータに対して計算されたハッシュであるため、このようなMitMはクライアント証明書認証を破ります-MitMシナリオでは、クライアントは「正しい」証明書を表示せず、したがって、サーバーが検出する誤った署名を計算します。
クライアントの観点から、ifクライアント証明書がサーバーによって要求され、クライアントによって表示されました- thenクライアントは、真のサーバーがMitMを検出することを認識しています。クライアントはMitM自体を検出しません。また、進行中のMitM攻撃がある場合、クライアントは実際に攻撃者と通信しており、攻撃者はクライアントに「ところで、現在攻撃されている」とは伝えません。
その意味で、クライアント証明書は真のMitM（別名「両面偽装」）を防ぎますが、より単純な詐欺（片面偽装、つまり偽のサーバー）からは保護しません。
結論：相互クライアント/サーバー認証（両方に証明書を送信する）を使用したSSLが存在する場合、MitMを成功させるには、攻撃者がクライアントとサーバーの両方の不正なCA。ただし、攻撃者が不正なCAをクライアントにのみ植え込める場合、クライアントは依然としてかなり悪い状況にあります（完全なMitMが妨害されている場合でも）。
安全なパブリックプライベートキーテクノロジーと同様に、クライアント側の証明書はMITMに対する保護を提供します。
この側のクライアント側の証明書の主な問題は、フィッシングまたは攻撃者が証明書/秘密鍵をエンドユーザーから取得することです。これは通常、サーバーからよりもはるかに簡単です。これは、エンドユーザーがセキュリティについてよく知らないためです。攻撃者がpk/certificateを取得すると、pk/certificateを使用してデータを再暗号化できるため、クライアントからのすべての情報を中継することでMITM攻撃を実行できます。
MITM攻撃を完全に成功させるには、クライアントとサーバーの両方のpk /証明書が必要です。それ以外の場合は、通信の一部を復号化できないためです。
（証明書ストアの操作を含まない）MiTMの厳密な定義に固執する場合、その答えは TLS RFC、付録F.1.1 ： "サーバーが認証されると、チャネルは中間者攻撃から保護されます "。したがって、純粋なMiTMの場合、クライアント証明書は必要ありません。