VPNSはアクティブな中間者攻撃に対して脆弱ですか？
SSL/TLSでは、中間者攻撃は不可能であることは知っています。たとえば、アリスとボブが通信しようとしていて、トルディが中間者攻撃を実行しようとしている場合、アリスがボブから公開鍵を取得すると（ただし、実際にはトルディがアリスをだましている）、公開鍵は認証局のため、機能しません。
SSHについては、サーバーへの最初の接続のみが、中間の攻撃でアクティブな男性に開かれている可能性があります。これは、最初の接続時に、クライアントがサーバーの公開鍵を$ HOME/ssh/known_hostsファイルに記録するためです。その後のすべての接続では、このファイルをチェックして公開鍵が一致することを確認します。
しかし、VPN暗号化は接続設定でどのように機能しますか？証明書は、SSL/TLSのように対称キーを渡すために使用されますか？そうでない場合、これにより、VPNはキー交換中のアクティブな中間者攻撃に対して脆弱になりますか？
中間者攻撃から保護するために、通信のエンドポイントの少なくとも1つは、他のエンドポイントに関する事前の知識が必要です。通常、サーバーは適切なサーバーと通信していることを確認するのはクライアントの責任です。サーバーはあらゆるクライアントが接続できる可能性があるためです。この事前知識を提供する種類のインフラストラクチャの一般的な用語は 公開鍵インフラストラクチャ です。
HTTPSの場合、通常、事前知識は 認証局 の中間ステップに付属しています。 Webブラウザーには、事前定義されたCAのリストとその公開鍵が含まれており、公開鍵がCAの秘密鍵によって署名されていることを示すことができれば、Webサイトを正規のものとして受け入れます。
SSHの場合、事前の知識は通常、以前にサーバーにアクセスしたことから得られます。クライアントはサーバーの公開鍵を記録し、サーバーの公開鍵が記録されていない場合は続行を拒否します。 （これは certificate pinning を使用したHTTPSにも存在します。）最初の接続では、SSHユーザーが公開鍵を検証します。
VPNソフトウェアが従う標準はありません。 VPNソフトウェアのドキュメントを読む必要があります。エンタープライズ展開では、サーバー証明書をVPNソフトウェアと一緒に従業員のコンピューターに展開するか、MITM攻撃を恐れない企業ネットワーク内からVPNへの最初の接続を従業員に要求するのが一般的です。証明書はVPNソフトウェア構成に保存され、サーバーの公開キーが変更された場合、VPNクライアントは接続を拒否します。
自分用または組織用にVPNサービスを展開する場合は、実際に使用する前に、インストール時にサーバー証明書をプロビジョニングする必要があります。安全なネットワークが利用できない場合は、証明書を送信するために他の通信チャネルに依存する必要があります。ユーザーを特定する方法であればメールでもかまいませんが、GPGキーなどの既存のインフラストラクチャに依存することをお勧めします（署名付きメールで証明書を送信します）。もちろん、問題を次の方法に移すだけです。 GPGキーを確認します。
クラウドベースのVPNサービスを使用している場合、そのサービスは証明書（HTTPSを介して提供されるWebページなど）を検証する方法を提供し、証明書のインストール方法または初回使用時の検証方法を文書化する必要があります。繰り返しになりますが、すべてのVPNソフトウェアが従う単一のプロセスはありません。
VPNは、適切に設定されていれば、多くのMiTMから保護しますが、すべてではありません。 VPNは通常、自分のコンピューターとVPNのゲートウェイの間のほとんどのMiTMから保護しますが、メッセージ/トラフィックが宛先に到達すると、半匿名化されず、「完全に匿名」ではないため、1つまたは（通常は+）になります。トラフィックの内容に侵入して変更できる複数の攻撃。さらに、PPTP、LT2P、およびWPA2にはすべて、MiTMおよび他の類似の攻撃の両方に対して脆弱になる可能性のある既知の欠陥があります。 WPA2は、特に辞書攻撃に対して脆弱です。私が書いたものに関連する詳細情報とデータ/コンテキストを追加するには、以下を参照してください：
https://help.riseup.net/en/vpn/security-issues
最初のリンクは要点を示して読みやすく、2番目のリンクは詳細を提供します。