企业防火墙背后的网络流量

Question

我在公司防火墙后面工作，该防火墙阻止了 Windows 和 Ubuntu 上除网络浏览器和系统更新之外的几乎所有应用程序的网络流量。

当我尝试使用 curl、git、python 等连接到外部资源时，出现 SSL/TLS 错误。我能够成功地忽略这些应用程序的 SSL/TLS，并且它们按预期工作（例如curl -k成功）。

关于此类问题的工作原理，我有几个问题：

• 由于忽略 SSL/TLS 有效，这是否意味着相关端口对 TCP/HTTP 流量开放，而不对 TLS/HTTPS 流量开放？

• 为什么浏览器能够apt install <package>通过 HTTPS 连接，而其他应用程序却不能？

• 是否有一个不损害安全性且不涉及访问防火墙设置的通用解决方案？

Answer 1

由于忽略 SSL/TLS 有效，这是否意味着相关端口对 TCP/HTTP 流量开放，而不对 TLS/HTTPS 流量开放？不，这意味着有一些（可能是透明的）代理可以拦截 HTTPS，也可能拦截 HTTP 流量。使用SSL 拦截， HTTPS 流量在代理上被解密，可能是为了检查它是否受到威胁或数据泄漏。这个中间人“攻击”的工作原理是将原始 HTTPS 连接分成两部分：一个在客户端和代理之间，一个在代理和目标服务器之间。由于代理无法访问原始证书私钥，它将使用由代理特定 CA 签名的动态创建的证书。如果此代理 CA 受信任，访问将顺利进行。但如果它不受信任，它就会崩溃——这就是你所看到的。如果您简单地禁用证书验证，它似乎可以工作，尽管它也会盲目地接受攻击者的恶意 SSL 拦截。为什么浏览器和 apt install 可以通过 HTTPS 连接，而其他应用程序却不能？不幸的是，没有一个信任库。浏览器有自己的，Python 可能有自己的，Java 有自己的，应用程序可能有自己的等等。因此，虽然代理 CA 可能已添加到某些信任存储中，但它可能没有添加到其他信任存储中。是否有一个不损害安全性且不涉及访问防火墙设置的通用解决方案？解决方案是将受信任的代理 CA 添加到所有必要的信任库中。但同样，没有单一的，所以需要做什么在很大程度上取决于系统的确切设置和所使用的应用程序。有一些标准位置可供查找（取决于操作系统和浏览器），但这些位置通常不包括系统上使用的所有可能的信任库。