コーヒーショップWIFI経由でVPN接続を確立しても安全ですか？
仕事用のラップトップでは、定期的にVPN接続を作成して、リモートデスクトップからWebサーバーに接続しています。ランダムな人々が同じwifiネットワークに接続しているコーヒーショップでこれを行うのは安全ですか？
はい、VPN接続は、コンピューターとリモートVPNホスト間の接続を暗号化します。カフェやインターネットでトラフィックを盗聴する人にとっては、接続は意味不明なものに見えるだけです。 VPNを使用していない場合でも、HTTPS経由で送信されるすべてのコンテンツに同じことが当てはまることは注目に値します。
また、現在のバージョンのMicrosoftターミナルサービス（リモートデスクトップなど）を使用している場合は、リモートデスクトップ接続自体も暗号化されているため、VPNの接続は（セキュリティの観点から）厳密には必要ありません。ただし、この設定はネットワークの管理構成によってオプションで減らすことができるので、VPNはまだ悪い考えではありません。
すでに述べたように、公衆無線ネットワークでVPNを使用することは「安全」です。 VPNは証明書を使用して、コンピューターとVPNサーバーとの間に暗号化されたデータストリームを確立します。これを確認するには、wiresharkなどのツールを使用できます。しかし、少なくとも理論的には不安の可能性はあると思います。誰かが実際のアクセスポイントと同じSSIDで偽のアクセスポイントを作成し、中間者攻撃を実行できます-とにかくSSL VPNの場合。コンピュータが実際のAPを選択するためには、偽のAPからより強い信号を取得する必要があります。
詳細については、次のリンクを参照してください。 Secure Access SSL VPNでのSSLStrip攻撃方法の軽減
「ターミナルサービスの現在のバージョン」にはVPNが必要ない可能性があるという@AJヘンダーソンの回答に関して、クライアントが「最新」である場合でも、グループポリシー内のAD設定を使用すると、セキュリティが弱まり、Wifiシナリオが作成される可能性があることを知っておく必要があります。安全ではない。これは多くの場合、より広範な機能を有効にするトレードオフとして行われます。
これは実際には、使用しているVPNの種類によって異なります。両側（この用語が適用される場合はクライアントとサーバー）で適切に構成する必要があります。
一部のPPTPサーバーは、デフォルトで暗号化を提供していません。さらに、適切な認証形式を使用していることを確認する必要があります（ このアドバイザリ）を参照 例えば）。
OpenVPNおよびIPsec（場合によっては）は、X.509証明書を使用して（少なくとも）サーバーを認証します。これは、HTTPSに影響を与えるのと同じPKIの問題の影響を受けます。
接続するときは、リモートパーティの証明書を正しく確認する必要があります（通常は証明書を使用）。より具体的には、証明書が信頼されていること、およびその名前が探しているものと一致していることを確認する必要があります。正しい実装はこれらの検証を実行する必要があります。
不正な/侵害されたCAの問題が発生することもありますが、これはかなりまれだと思います（願っています）。可能であれば、マシン上の信頼できるCAのリストを絞り込みます。
共有秘密を使用したIPsec。共有秘密が共有よりも秘密である限り、これらは問題ありません。この共有秘密の知識により、MITMは サーバーを偽装 することができます（そのページのリンクも興味深いはずです）。
組織が大きければ大きいほど、その共有秘密を十分に秘密に保つことは難しくなるようです。さまざまな大学のVPNの説明をすばやく検索すると、これらの秘密の一部が実際に公開されていることがわかります。
PKIの問題にもかかわらず、証明書ベースのソリューションでは、証明書の一致する秘密キーがどのユーザーとも共有されないため、サーバーを偽装することがより困難になります。
そのため、はい、VPNは（少なくともリモートVPNネットワークの範囲で）信頼されていないネットワーク上でユーザーを保護できますが、すべてと同様に、適切に構成する必要があります。
VPNは、次の要件が満たされている限り、ニーズに適合します。
- VPNエントリノードは、更新された証明書などで認証されます
- 証明書は安全です（証明書に問題があります。つまり、証明書のMD5サインが弱いことが証明されています）
- VPNの認証メカニズムは安全です（一部の認証メカニズム、つまりMS-CHAP v2でいくつかの問題が報告されています）
- チャネル暗号化メカニズムは安全です（私は既知の欠陥を認識していません）
VPNの設定方法によって異なります。たとえば証明書を使用するなどして、クライアントがサーバーのIDを検証する場合は、はい。そうでない場合でも、MITMを使用できます。
1番目のリスク：OS
提案されたソリューションのセキュリティに依存する最初のポイントは、VPNの出発点であるOSのセキュリティです。
管理者が多すぎると、VPNを使用して弱いOSから会社のネットワークに到達することは何よりもセキュリティ上のリスクであり、VPNの着信接続は通常信頼できる接続として分類されるため、大きなものになります（会社のファイアウォールで、どこでも会社IPS）。
一般的な現実のシナリオを次に示します。コンピュータはキーロガーによってホストされています。 （実際のエクスペリエンスの戻り値：通常の数値は1を上回っています。VPNソリューションによるエンドユーザーコントロール：通常の数値は1を下回っています）。
2番目のリスク：トンネルの横のトラフィック
正しく構成されたVPNは、暗号化されていないトラフィック（つまり、通常のIP）によるインターネットの可視性をブロックする必要があります。すべてがesp（50）ah（51はほとんど使用されなくなった）または443/tcp/IP aka httpsを通過する必要があります。
現実のシナリオ：VPN構成は稼働していますが、ワイヤレス接続のトラフィックbedideトンネルは開いており、システムで何も制御せず、管理者は最初はそれを表示するのに十分なネットワークを認識していません。
tcpdump -i en1という名前のインターフェイスでVPNを起動するたびにen1と入力して53/udp/IP、67/udp/IP…がトンネルエントリの横にまだフラッディングしていることを確認する必要はないでしょう:) 500/udp/IPだけではありません。
Wi-Fi環境でネイバーがすでにPCに接続されているかどうかをarp -aで確認しないでください。
3番目のリスク：魔法のように受け入れられた証明書
ほとんどのOSでは、ユーザー、さらには管理者、さらにはセキュリティを意識した管理者でさえ、リモート証明書を受け入れるオートマジック機能を信頼する傾向があります。この機能はブラウザ内に隠れており、時にはOS自体にも隠れています。検証しない信頼は魔法です。リスクです。
この魔法から、VPNを構築するために最初にInternet Explorerを起動する必要があることが示唆された場合、これは調査と恐怖の一生に値するものです。
https接続上に構築されたVPNで会社に接続する場合、会社は会社の証明書を確認して、Wi内の偽のWebサーバーによって提示された証明書を使用していないことを確認する必要があります-Fi近所。あらゆる状況で確認できる独立した文書に、会社の証明書のフィンガープリントが必要です。この接続はmagic trustの上に構築しないでください。