web-dev-qa-db-ja.com

サードパーティを使用せずにMitM攻撃を回避できますか？

私はこの分野に少し慣れていないので、中間者攻撃について読んでいます。提供されているソリューションのほとんどすべてが、証明機関などの信頼できるサードパーティを使用することです。

これを2つの通信する当事者だけでは解決できないことを意味する、不可能ではない結果はありますか？ CAを使用せずにそれを行う方法はありますか？

authenticationcertificatesman-in-the-middlecertificate-authority
6
JustAnotherUser

HTTPSを使用する場合でも、CAを使用する必要はありません。クライアントがサーバーに接続する前に安全な（改ざん防止）方法でこの証明書のコピーまたは類似の（つまり指紋）をクライアントに提供する場合、クライアントがサーバーを検証できるように、サーバーで自己署名証明書を使用できます。予想されるサーバーと通信すること。クライアントがサーバーを確認できない場合、中間者攻撃が可能です。

CA署名付き証明書の概念（つまり 公開鍵インフラストラクチャ（PKI） ）は、自己署名したリーフ証明書をすべての関係者と共有すると拡張できないため、作成されただけです。 CAでは、ブラウザ/ OSにトラストアンカー（ルート証明書）のリストがあり、信頼されたルートからリーフ証明書へのトラストチェーンに基づいてサーバー証明書への信頼を導き出すことができます。このメカニズムのため、共有する必要があるのは信頼できるルートCAだけですが、すべての可能なサーバー証明書ではありません。

事前共有証明書または同様の公開情報（SSHサーバーのフィンガープリントなど）とは別に、両側で共有シークレットを使用してMITM耐性のある接続を確立することもできます。これは、WPAで保護された家庭用Wifiの典型的なケースです。

MITMに対する限定的な保護は、Trust On First Use（TOFU）によって実現されます。この場合、ピアのIDは最初の接続から保存され、攻撃者が最初の接続に存在しないことを期待して次の接続に適用されます。これは、たとえば、HTTPSで自己署名証明書を受け入れる場合に行われます。

6
Steffen Ullrich

SSHは、信頼関係の確立にCA（または実際には第三者）が関与する必要のないTOFU（Trust on first use）の一例です。

ほとんどの事前共有キー（例：WPAに使用、またはVPNソリューションで使用）は、正しく使用され、CAを介して信頼を確立する必要なしに、MitM攻撃に対する保護を提供できます。 （またはPKI）。暗号化トークンを使用する必要はありません。

また、MitMはCAによって促進される可能性があること（たとえば、CAがIDを検証するために必要なチェックを実行せずに証明書を発行する場合-侵害、法的圧力、または悪意のため）、およびPKIを使用することで、必ずしもMitMに対する保護を提供するわけではありません-与えられたトークン（キー）が（アイデンティティの）主張を表すと合理的に信じられていることを単純に確立します。また、貧弱な暗号の選択は、たとえば、それらの主張/主張のすべてを無効にする可能性があります。

更新：

以下のコメントで@ Steffen Ullrich が指摘しているように、TOFUは最初の接続時にMitMの影響を受けます。これは軽減できます（たとえば、提示されているホストキーを検証するためのメカニズムを提供することにより）。その最初の接続に続いて、MitMから安全であるか、完全に公開されています。

信頼を確立するための別のアプローチとしてTOFUを指すつもりでしたが（基本的にユーザーが理解することはできません）、Steffenは間違いなく、TOFUとPKIが根本的に異なるアプローチを使用してIDを検証し、TOFUが設計上の決定を下すようにしています最初の接続時のMitMのリスクに対処するしないため、2つの信頼モデルはMitMに対する保護機能に異なる影響を与えます。

なぜMitMの文献がPKIに言及しているのかという質問だったので、これは部分的な答えです。MitMから保護するためのより一般的なアプローチのうち、PKIベースのソリューションは、TOFUのような他のアプローチよりも多くの保護を提供します。

1
iwaseatenbyagrue

クライアントは、サーバーが本人であることを確認する方法を必要とします。

これを確認するにはさまざまな方法があります。

  1. サードパーティを信頼する：HTTPSは信頼できるCAを使用します。 PGPはweb-of-trustを使用して、送信者と受信者を結合しようとします。
  2. 初めて使用するときに信頼する：SSH（デフォルト）は、ユーザーが初めて接続するときにサーバーを信頼するように要求し、サーバーが変更されるとSSHがユーザーに警告します。また、ブラウザが自己署名証明書を処理する傾向があるため、「例外」を記録できます。
  3. 範囲外のメカニズムを介してサーバーの公開鍵を事前共有します。これは、SSHと自己署名証明書を実際に安全に行うための方法です。
0
Douglas Leeder