☰

对 HTTPS 代理的困惑

tag-icon • tag-icon proxy encryption https
对 HTTPS 代理的困惑

我知道 HTTP 代理的工作原理，但我不确定 HTTPS 代理的工作原理。更具体地说，我对加密部分感到困惑。

因此，客户端使用 HTTPS 连接到代理。我明白了。现在假设用户想要通过该代理连接到 Gmail。

  1. 代理是否必须首先与 Gmail 建立 HTTPS 连接？
  2. 那么客户端/服务器 hello 是如何完成的？客户端是否通过 https 加密客户端 hello，将其发送到代理，代理再解密，使用与 gmail 约定的加密方法加密并将其发送到 gmail？
  3. 然后，在执行客户端/服务器问候并商定加密方法后，客户端不会感到困惑吗？因为如果所有请求都通过代理，加密方法难道不应该只有一种吗？或者客户端是否根据发送到的主机加密其请求，而不管 IP 地址如何？
  4. 还有一件事；如果代理应该用自己的地址替换数据包的发送方地址，那么数据包不应该完全解密吗？因为如果不是这样，那么如果数据全是乱码，代理怎么知道在哪里插入它的 IP？或者发送方部分没有加密？

答案1

“没有 HTTPS 正向代理”这一评论是不正确的。它们非常常见。任何规模适中的公司都会为 SSL 引入显式正向代理，以便他们可以解密 https 流量以进行监控、记录和过滤 - 常见的委婉说法是“合规性报告”。

以下是您可能已经知道的一些背景知识：

HTTPS 会话的初始握手包含三个部分：

  1. 问候： ClientHello包含其支持的 TLS 版本和密码的消息，以及ServerHello包含类似信息的消息。此步骤和下一步均未加密。

  2. 证书交换：服务器提供它的 TLS 证书，客户端需要决定是否信任该证书——通常对证书颁发机构签名的证书采取隐式信任方式，而对于自签名证书则需要用户干预。

  3. 密钥交换- 这方法使用在步骤 1 中决定的；最简单的方法是 RSA 密钥交换类型的交易：客户端使用随机数生成密钥，并使用服务器的公钥对其进行加密。使用服务器的私钥对其进行解密（只能使用公钥加密，没有私钥则无法解密，这很微妙，但对许多人来说却很令人困惑）。

从这里开始，通信将完全加密，几乎所有的 TCP/IP 数据包都经过加密（路由所需的标头/字段除外）。

您的问题的答案是，正向代理要求代理完全解密 HTTPS 通信。客户端永远不会直接与目标服务器握手（有时不知道它不是，我将在下面提到）。

以下是来自Palo Alto 网络关于正向 HTTPS 代理的工作原理（PAN-OS 指的是其网络 SW）：

  1. 客户端正在尝试使用 HTTPS 访问 www.google.com。流量符合解密策略。
  2. 此流量由我们的 SSL 代理引擎处理，并且 www.google.com 的证书由我们的内部 PKI 生成（由 CA 证书签名）。
  3. PAN-OS 正在代理 ssl 流量并与 Web 服务器建立新的 ssl 连接。
  4. Web 服务器正在开始与 PAN-OS 设备握手。
  5. PAN-OS 设备正在与客户端完成 SSL 握手，并在 Server Hello 消息中出示生成的证书。

这（如果是恶意的）是一种明显的中间人攻击 - 它将两方交易：PC ⟺ Google - 转变为两个独立的交易：PC ⟺ 代理和代理 ⟺ Google。

边注

由于正向代理主要用于监控 SSL 流量，因此有趣的是，该 PAN 链接中还讨论了非代理方法 -入站‘检查/解密’这要求防火墙拥有服务器证书和密钥，因此能够通过简单的数据包监控完全解密通信。顺便说一句，他们宣传这是一项关键功能，而人们希望它只有很少的用例，这有点令人不安——它要求防火墙的操作员拥有第三方网站的公钥和私钥——例如谷歌的私钥。人们会认为这不会很常见。

正向代理的实现方式有很多种，我几乎只涉及其中一种——大多数（如果不是全部）正向代理都是作为“透明”正向代理实现的，这意味着客户端根本没有配置为连接到代理，防火墙/代理会介入事务。上面描述的正向代理是“透明”代理。一旦客户端接受了来自代理的证书（如果是 CA 签名的证书，通常是自动的），客户端计算机将收到代理修改后的数据包，使其看起来像是来自原始服务器（例如 google）。

更新以从评论中提取信息

  1. 实现正向代理的另一种方法是使用 TCP 隧道，这实际上会为加密数据创建一个包装器。此处的初始事务未加密，而是由客户端使用 CONNECT 请求向代理服务器发起的。建立连接后，客户端与服务器之间的通信将被加密。请参阅此内容了解详情。

  2. HSTS（HTTP 严格传输安全）是一种协议，旨在防止恶意攻击者拦截来自服务器的将当前事务从 http 转换为 https 的请求。其背后的理论是，在 http 上实施中间人攻击是微不足道的，如果这个“代理”代理看到转换请求，它就可以欺骗转换到 https。它不会直接影响 https 转发代理的工作方式，但与之相关；这里是一个更好的解释

  3. MITM 攻击、HTTPS 和代理服务器。这是一个很好的解释关于为什么使用代理服务器的 MITM 攻击在使用“直接”HTTPS 时无效（即不是部分通过 HSTS 解决的 HTTP 到 HTTPS 转换）。以下是有关 MITM 攻击和 HTTPS 的附加信息，来自crypto.stackexchange。

我认为这回答了原始问题和更新的问题。如果我有任何错误或不清楚的地方，请告诉我，我会更新。

答案2

HTTPS 代理服务器与 HTTP 代理服务器没有什么不同，只是使用 HTTPS 代理，浏览器到代理服务器的连接是加密的。

但是你需要在代理服务器上部署证书，就像 https 网站那样，并使用文件pac配置浏览器以启用通过 SSL 连接到代理。

不同之处在于，例如，使用 https 代理服务器，防火墙无法看到您使用CONNECT方法连接到哪个主机。

有关更多详细信息和实际示例，请参阅此处的问题和答案https://stackoverflow.com/questions/56981993/https-proxy-server-only-works-in-switchomega

答案3

通过代理的 HTTPS 使用名为“CONNECT”的命令。这称为隧道，并使用带有 CONNECT 动词的 HTTP 请求消息在客户端和请求的服务器：端口之间建立中继。代理建立连接，向客户端指示连接（例如，返回 200 Connection OK），然后退出。

从此时起，客户端与终端服务器建立中继连接，类似于直接连接而无需代理。这用于设置 SSL/TLS 层，后续加密的 http 请求将在此层上进行。

相关内容