VPNプロバイダーは、知らないうちにSSLトラフィックをMitMできますか？
接続する場合は、VPN経由でgmailと言います。プロバイダーは、IPを公開せずにSSLを壊すことなくトラフィックを転送する方法を教えてください。トラフィックがプロバイダーをトンネリングするだけの場合、Gmailは私の実際のIPを知らないのですか？
Sslが壊れた場合は無効な証明書について考えましたが、palo altoのような次世代ファイアウォールは、ユーザーに気付かれずにsslトラフィックの詳細なパケット検査を行えるとどのように主張していますか？ VPNプロバイダーが同様のボックスを使用してそれを復号化できないのはなぜですか？
VPNプロバイダーが私について収集できるデータの量に少し興味があります。ここで私を助けてくれるといいのですが。
プロバイダーは、IPを公開せずにSSLを破らずにトラフィックを転送する方法を教えてください。
SSLはTCP= IPの上にある）の保護（暗号化のような）です。転送されるデータを変更せずに、基になるレイヤー（TCP、IP）を変更できます。つまり、暗号化はネットワーク層のIPアドレスが変更されても保持されます。
これは、暗号化されたメール（つまり、PGPまたはS/MIME）を持っていることに似ています。複数のメールサーバー経由で転送されたり、別のマシンに保存されたりしても問題ありません。メール自体の暗号化された部分とその内部コンテンツは変更されません。
...しかし、パロアルトのような次世代ファイアウォールは、ユーザーが気付かないでsslトラフィックの詳細なパケット検査を行えるとどのように主張していますか？
彼らはしません。 SSL接続の内部コンテンツを分析する必要がある場合、DPIシステムは中間の「攻撃」を行います。つまり、サーバーから見たSSL接続のエンドポイントであり、トラフィックを復号化して再度暗号化して提示します。クライアントに。接続の新しい証明書（DPIシステムによって作成されたもの）は信頼されないため、通常、これによりユーザーにセキュリティ警告が表示されます。ただし、ユーザーがDPIアプライアンスを明示的に信頼している場合、これはユーザーに対してより透過的にすることができます。
これの詳細については、 会社のSSLプロキシサーバーはどのように機能するのですか？ 、 ディープパケットインスペクションSSL：DPIアプライアンスが証明書の警告を防ぐ方法 または 一般的です企業がMITM HTTPSトラフィックを実行する方法は？ 。
VPNプロバイダーが同様のボックスを使用してそれを復号化できないのはなぜですか？
それは実際にこれを行うことができました。
理論的には、ユーザーは、企業で行われているのと同様に、SSLトラフィックを検査するためにVPNプロバイダーを明示的に信頼する必要があります。ただし、たとえばVPNプロバイダーが提供するVPNソフトウェアをインストールした場合、このソフトウェアは実際には、SSLインターセプトについてコンピューターをVPNプロバイダーを静かに信頼し、プロバイダーが暗号化されたトラフィックを傍受し、さらには変更することさえできないことに気付かない可能性があります。この信頼できる認証局のサイレントインストールは、実際には多くのウイルス対策製品が行っていることであり、暗号化されたトラフィックを盗聴し、暗号化された接続内で配信される攻撃からユーザーを保護します。
理論的には、プロバイダーが各SSL接続の証明書チェーンを調べ、それを期待されたものと比較することで、プロバイダーがこれを行っていることを知ることができます。または、ローカルで信頼されている認証局を見て、追加された認証局があるかどうかを確認できます。それでも、VPNプロバイダーからソフトウェアをインストールする場合、プロバイダーはブラウザーなどのシステムの一部を変更して、検査を非表示にすることもできます。これは、VPNプロバイダーから提供されたソフトウェアに限定されません。インストールしたソフトウェアは、実際にそのような変更を加える可能性があります。
HTTPS検査を検出するにはどうすればよいですか？ も参照してください。
簡単に言えば、VPNを使用していない場合でも、VPNプロバイダーはISPにできることは何でもできます。
これには、ブラウザが中間ボックスの中間証明書を発行したルートCAを信頼している場合、TLSの破壊が含まれる場合があります。 ISPからVPNプロバイダーに移行しないという信頼を移しています。
このようなミドルボックスのほとんどでは、ユーザーは新しいルートCAをインストールする必要があります。あなたはおそらくあなたがあなたのVPNプロバイダーからの証明書をインストールしなかったので、あなたはそれから保護されています。しかし、過去には有効なブラウザ信頼中間証明書を備えたアプライアンスがいくつかありました。まだあるかどうかはわかりません。
VPNプロバイダーは、知らないうちにSSLトラフィックをMitMできますか？
特にこれに関して、彼らがウェブサイトの秘密鍵を持っていない限り、あなたは気づくことができます。ブラウザでVPNプロバイダーの証明書を信頼している場合は、各サイトが使用している証明書を積極的に確認する必要がありますが、注意を払えば気付くはずです。 VPNのあるサイトとないサイトの両方にアクセスする場合、Certificate Patrolなどのブラウザ拡張機能が役立ちます。彼らは証明書の変更を通知します。
トラフィックがプロバイダーをトンネリングするだけの場合、Gmailは実際のIPを知らないのですか？
多分;場合によります。元のIPアドレスはVPNプロバイダーのアドレスです。ただし、Gmailまたは別のWebサイトがJavaScriptまたは別の言語のスクリプトをブラウザーに送信し、ブラウザーがそれを受け入れて実行し、IP（またはその他の、さらにプライベートな情報）を収集する場合は、それを元の-またはサードパーティに送信します！
その送信が途切れていないTLSを介して行われる場合、あなたの情報は、送信先のサイトと、そのサイトが喜んでまたは望まずに共有するすべての人にのみ提供されました。
その送信が暗号化されていない場合、あなたと彼らの間の誰もがそれを見ることができます。
その送信が壊れた暗号化で暗号化されている場合、それは非常に複雑ですが、上記の2つの極端の間のどこかです。
Sslが壊れた場合は無効な証明書について考えましたが、palo altoのような次世代ファイアウォールは、ユーザーに気付かれずにsslトラフィックの詳細なパケット検査を行えるとどのように主張していますか？
Webサーバー自体が使用する証明書とまったく同じ秘密鍵のコピーがあるためです。 Webサーバーがその秘密鍵を使用してTLSトラフィックを復号化するのと同じように、アプライアンスはWebサーバーの秘密鍵を使用してトラフィックのコピーを復号化します。
VPNプロバイダーが同様のボックスを使用してそれを復号化できないのはなぜですか？
エンドWebサイトのTLS秘密キーのコピーを持っているVPN会社は、主要な国家国家の行為者、例外的な犯罪活動、および/またはHeartbleedのような重要なゼロデイエクスプロイトの最先端を含む非常に例外的な状況になります。
VPNプロバイダーが私について収集する可能性のあるデータの量に少し興味があります。
少なくとも、あなたが彼らに許可すると思っているのと同じくらい。
VPN経由でDNSリクエストを送信しますか？彼らはそれを見ることができます。そうでない場合、ISPはそれを見ることができます。
HTTPトラフィックを許可しますか？彼らはそれを見ることができ、そして輸送中に変更することができます。サードパーティのトラフィックも含まれます。
彼らは間違いなく、どのIPアドレスに移動するか、そして移動するデータのパターンを確認できます。次に、それを多くの人のトラフィックの統計的に有意な分析、および意図的なテストと収集した公開情報と照合します。
- つまり、単純なページリクエストパケットにするには大きすぎるパケットを https://security.stackexchange.com ？に送信します。入力したものをサイトのStackexchangeネットワークに送信しています。これらの大規模な送信と新しい質問および回答との単純な相関関係により、stackexchangeユーザー名がすぐに明らかになります。
壊れた暗号化アルゴリズムを許可しますか？彼らはそれを見ることができるかもしれませんし、できないかもしれません。
あなたが彼らが主張するものにかかわらず（またはあなたのトラフィックに関係するすべてのサーバーとその会社とその中の人々の管理を管理している政府に依存して主張することを余儀なくされています-あなたがVPNエンドポイント、または企業管理、または複数の下請けサーバー管理者はRepressiveRegimeXに属しており、RepressiveRegimeXはそれに対して非常に強力です。
少なくともしばらくの間、Firefoxに Matrixプラグイン （アクセスしたサイトによって行われているサードパーティのリクエストのマッピングを表示する）と HTTPS Everywhere を試してみてください= HTTPの使用を制限します。
また、Firefoxでabout：configに移動し、tlsを検索して許可されているTLSバージョンを確認し、ssl3を検索して有効になっている暗号スイートを確認します。
使用する各ブラウザーで SSLLabs に移動し、クライアントテストを行って、そのブラウザーでそのマシンで許可されている脆弱性を確認します。それらを削除します。
高度なオプションとして、 wireshark または別のツールを使用して、VPNを実際に通過しているものとそうでないものを監視します。実際のTLS接続が行われているのを確認できる場合とできない場合があります。そのため、ネゴシエートされた暗号スイートまたはアルゴリズムの選択を確認できます。
- DNSリクエストであるUDPポート53の送信先に特に注意してください。 VPNプロバイダーを介して、またはそうではありませんか？
通常の状況下ではNoなので、既存の回答に不満があります。
VPNは単なる接続です。 SSLをブロックまたは削除しようとする可能性がありますが、信頼できる証明書チェーンに干渉されない、信頼できる別のサイトへのSSL接続を行う場合、ブラウザーとの間のデータはVPNプロバイダーから暗号化されます。
彼らはあなたがどこに接続しているかを[大まかに]見ることができます。 IPアドレスとポートが表示されます。 TLSを介したすべてのコンテンツ（HTTPでのホスト要求を含む）は、それらから離れて暗号化されます。 VPNプロバイダーは、ブラウザーが作成しているDNS要求を確認することもできますが、これはユーザーが何をしているのかを示しているわけではありませんdoingこれが問題である場合は、個別に暗号化されたDNSを取得できます。
Palo Altoのファイアウォールwillは取り除かれ、再署名されますが、これがユーザーに正当に見える唯一の方法は、ユーザー（または企業のコンピュータープロバイダー）がPalo Altoのルート証明書をインストールした場合です。これは標準的なセットアップとはかけ離れています。
SSLとTLSはIPアドレスを気にしません。 Gmailは機能するために実際のIPを知る必要はありませんが、それらおよび他のサービスは、大陸間ホップ（Torでより一般的）を疑わしい動作としてフラグを立て、それがより頻繁にあなただけであることを確認することができます。
おそらく、それらがあなたのブラウザが信頼するルートCAの秘密鍵を持っているなら、そうです、あなたが証明ピン留めを使うなら、これを検出できます。 CAを信頼せず、接続する各サイトの証明書を保存します。
ここでのMITMの状況は、VPNの使用によって複雑になっています。 VPNは、VPNプロバイダーへのトラフィックを暗号化します。そこからのトラフィックは、ISPからのトラフィックとまったく同じですが、この場合、ISPはVPNと同じように動作します。したがって、VPNプロバイダーは、ISPが取得できるすべての情報を持っています。