提供商如何在不暴露我的 IP 且不破坏 SSL 的情况下转发流量。

SSL 是位于 IP 之上的 TCP 之上的保护（如加密）。可以在不更改传输数据的情况下更改底层（TCP、IP）。这意味着即使您在网络层的 IP 地址发生变化，也可以保持加密。

这类似于加密邮件（即 PGP 或 S/MIME）。它是否通过多个邮件服务器传输、存储在不同的机器上等都没关系——邮件本身的加密部分及其内部内容不会改变。

...但是像帕洛阿尔托这样的下一代防火墙如何声称他们可以在用户没有注意到的情况下对 ssl 流量进行深度数据包检查？

他们没有。如果需要分析 SSL 连接的内部内容，DPI 系统会进行中间人“攻击”，即从服务器的角度来看，它是 SSL 连接的端点，对任何流量进行解密并再次对其进行加密以呈现给客户。通常这会导致向用户发出安全警告，因为连接的新证书（由 DPI 系统创建）不受信任。但是，如果用户明确信任 DPI 设备，则可以使这对用户更加透明。

有关详细信息，请参阅公司中的 SSL 代理服务器如何工作？,深度包检测 SSL：DPI 设备如何防止证书警告？还是公司对 MITM HTTPS 流量的常见做法？.

为什么VPN提供商不能只使用类似的盒子来解密呢？

它实际上可以做到这一点。

只是，理论上用户需要明确信任 VPN 提供商来检查 SSL 流量，这与公司所做的类似。但是，例如，如果您安装了 VPN 提供商提供的 VPN 软件，该软件实际上可以默默地信任 VPN 提供商的计算机进行 SSL 拦截，这样您就不会意识到提供商可以嗅探甚至修改加密流量。这种信任证书颁发机构的静默安装实际上是许多防病毒产品所做的，因此它们可以嗅探加密流量并保护用户免受加密连接内传递的攻击。

理论上可以通过查看每个 SSL 连接的证书链并将其与预期的比较来发现提供商正在执行此操作。或者可以查看本地受信任的证书颁发机构，看看是否添加了一个。尽管如此，如果您从 VPN 提供商处安装软件，提供商也可能会更改您系统的某些部分，例如浏览器，以便对您隐藏检查。这不仅限于 VPN 提供商提供的软件 - 您安装的任何软件实际上都可以进行此类更改。

另请参阅如何检测 HTTPS 检查？.

简短的回答是：如果您不使用 VPN，您的 VPN 提供商可以做任何您的 ISP 可以做的事情。

如果您的浏览器信任根 CA，这可能包括破坏 TLS，该根 CA 为中间盒颁发中间证书。您正在将不这样做的信任从您的 ISP 转移到 VPN 提供商。

大多数此类中间框要求用户安装新的根 CA。您受到保护，因为您可能没有从您的 VPN 提供商处安装证书。但是过去有一些设备具有有效的浏览器可信中间证书。我不确定是否还有一些。

VPN 提供商可以在我不注意的情况下对我的 SSL 流量进行中间人攻击吗？

关于这一点，除非他们有网站的私钥，否则你会注意到。如果您在浏览器中信任 VPN 提供商的证书，那么您当然必须更加努力地查看每个站点正在使用哪个证书，但是如果您注意的话，您会注意到。如果您在使用和不使用 VPN 的情况下访问网站，诸如 Certificate Patrol 之类的浏览器扩展程序会有所帮助；他们会通知证书更改。

如果流量只是通过提供商隧道传输，gmail不应该知道我的真实IP吗？

或许; 这取决于。原始 IP 地址是 VPN 提供商的 IP 地址；但是，如果 gmail 或其他网站向您的浏览器发送 Javascript 或其他语言的脚本，您的浏览器接受并运行这些脚本来收集您的 IP（或其他更私密的信息），然后将其发送给发起方或第三方！

如果该传输是通过完整的 TLS 传输的，那么您的信息只会被提供给它被发送到的站点以及该站点愿意或不愿意与之共享它的每个人。

如果该传输未加密，您和他们之间的每个人也可以看到它。

如果该传输是使用损坏的加密进行加密的，则它非常复杂，但介于上述两个极端之间。

如果 ssl 被破坏，我考虑过无效的证书，但是像帕洛阿尔托这样的下一代防火墙如何声称他们可以在用户没有注意到的情况下对 ssl 流量进行深度数据包检查？

他们这样做是因为他们拥有与 Web 服务器本身使用的证书完全相同的私钥的副本！正如 Web 服务器使用其私钥解密 TLS 流量一样，设备使用 Web 服务器的私钥解密其流量副本。

为什么VPN提供商不能只使用类似的盒子来解密呢？

拥有最终网站 TLS 私钥副本的 VPN 公司将是一种非常特殊的情况，涉及主要的民族国家行为者、特殊的犯罪活动和/或像 Heartbleed 这样的关键零日漏洞利用的前沿。

我有点好奇 VPN 提供商可能会收集多少关于我的数据。

至少你认为你允许他们这样做。

您是否通过 VPN 发送 DNS 请求？他们可以看到这一点。如果没有，您的 ISP 可以看到它。

你允许 HTTP 流量吗？他们可以看到——并在运输过程中改变——那。当心，这包括第三方流量。

他们肯定可以看到您要去哪些 IP 地址，以及您移动的数据模式。然后，他们可以将其与对大量人员流量的统计显着分析以及他们收集的故意测试和公共信息进行匹配。

• 即您向https://security.stackexchange.com发送了一些太大而无法简单的页面请求数据包？您正在向 Stackexchange 网站网络提交您输入的内容；这些大型传输与新问题和答案的简单关联将很快揭示您的 stackexchange 用户名。

您允许损坏的加密算法吗？他们可能会也可能不会看到这一点。

你肯定对他们记录的内容零了解，不管他们声称什么（或被迫声称取决于政府控制你的流量所涉及的每台服务器以及该公司及其人员的管理 - 如果你VPN 端点，或公司管理，或多个分包服务器管理员都在 RepressiveRegimeX 中，RepressiveRegimeX 对其具有很大的权力。

至少在一段时间内尝试使用带有uMatrix 插件的 Firefox （向您展示您访问的站点正在发出的第三方请求的映射），并使用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 请求，但这并不能说明您在做什么，因为浏览器会在您浏览时触发数百万个请求。如果这是一个问题，您可以获得单独加密的 DNS。

Palo Alto 的防火墙将被剥离和退出，但对用户来说这看起来合法的唯一方法是如果他们（或他们的公司计算机提供商）安装了 Palo Alto 的根证书。这与标准设置相去甚远。

SSL 和 TLS 不关心 IP 地址。Gmail 不需要知道您的真实 IP 即可运行，尽管它们和其他服务可能会将洲际跃点（在 Tor 中更常见）标记为可疑行为，并让您更频繁地验证它只是您本人。