Mar*_*ead 5 encryption proxy https
我知道 HTTP 代理的工作原理，但不确定 HTTPS 代理的工作原理。更具体地说，我对加密部分感到困惑。
因此，客户端使用 HTTPS 连接到代理。我明白了。现在假设用户想要通过该代理连接到 Gmail。
“没有 HTTPS 转发代理”的评论是不正确的。它们很常见。任何规模相当的公司都会采用 SSL 的显式前向代理，以便他们可以解密 https 流量以用于监控、日志记录和过滤目的 - 常见的委婉说法是“合规性报告”。\n
一些您可能已经知道的背景知识：
HTTPS 会话的初始握手包含三个部分：
\n\n问候语： ClientHello包含其支持的 TLS 版本和密码的消息，以及ServerHello包含类似信息的消息。此步骤和后续步骤均未加密。
证书交换：服务器提供其 TLS 证书，客户端需要决定是否信任该证书 - 通常通过对证书颁发机构签名的隐式信任来实现，并需要用户干预进行自签名。
从这里开始，将进行完全加密的通信，几乎所有 TCP/IP 数据包都已加密（路由所需的标头/字段除外）。
\n\n您的问题的答案是转发代理要求代理完全解密 HTTPS 通信。客户端从不直接与预期的服务器握手（有时不知道它不是，我在下面谈到）。
\n\n以下是Palo Alto Networks关于转发 HTTPS 代理如何工作的解释（PAN-OS 指的是他们的网络软件）：
\n\n\n\n\n\n
\n- 客户端正在尝试使用 HTTPS 访问 www.google.com。流量与解密策略匹配。
\n- 此流量由我们的 SSL 代理引擎处理，并且 www.google.com 的证书由我们的内部 PKI 生成（由 CA\n 证书签名）。
\n- PAN-OS 正在代理 ssl 流量并与 Web 服务器建立新的 ssl 连接。
\n- Web 服务器正在开始与 PAN-OS 设备握手。
\n- PAN-OS 设备正在完成其 SSL 握手，客户端在服务器 Hello 消息中提供生成的证书。
\n
这（如果是恶意的）是一个明确的中间人攻击 - 它将 2 方交易：PC \xe2\x9f\xba Google - 变成 2 个单独的交易：PC \xe2\x9f\xba 代理和代理 \xe2\x9f\ xba 谷歌。
\n\n由于转发代理主要用于监控 ssl 流量，有趣的是，在 PAN 链接中也讨论了非代理方法 -入站“检查/解密”，它要求防火墙具有服务器证书和密钥，因此能够通过简单的数据包监控完全解密通信。顺便说一句，令人有点不安的是，他们将其宣传为一项关键功能，而人们希望它只有很少的用例 - 它要求防火墙的操作员拥有第 3 方站点的公钥和私钥 -例如 Google 的私钥。人们会认为这并不常见。
\n\n转发代理的实现方式有很多种，我几乎没有涉及它们 - 许多（如果不是大多数）转发代理都是作为“透明”转发代理实现的，这意味着客户端根本没有配置为连接到代理，并且防火墙/代理将自身插入到事务中。上面描述的转发代理是一个“透明”代理。一旦客户端接受了来自代理的证书（如果是 CA 签名的证书通常是自动的），客户端计算机将收到代理修改后看起来像是来自原始服务器（例如 google）的数据包。
\n\n实现转发代理的另一种方法是使用 TCP 隧道，它可以有效地在加密数据周围创建一个包装器。这里的初始事务未加密，并且由客户端使用对代理服务器的 CONNECT 请求发起。一旦建立连接，客户端到服务器的通信就会被加密。详细信息请参阅此。
HSTS（HTTP 严格传输安全）是一种协议，旨在防止恶意攻击者拦截来自服务器的请求，将当前事务从 http 转换为 https。其背后的理论是，对 http 实施中间人攻击是微不足道的，如果这个“代理”代理看到转换请求，它就可以欺骗到 https 的转换。它不会直接影响 https 转发代理的工作方式，但相关；这是一个更好的解释
MITM 攻击、HTTPS 和代理服务器。这里很好地解释了为什么使用代理服务器的 MITM 攻击当前在使用“直接”HTTPS（即不是通过 HSTS 部分解决的 HTTP 到 HTTPS 转换）时无效。以下是有关crypto.stackexchange问题中关于 MITM 攻击和 HTTPS 的附加信息。
我认为这回答了原始问题和更新后的问题。如果我有任何错误或不清楚的地方，请告诉我，我会更新。
\n| 归档时间： |
|
| 查看次数： |
7177 次 |
| 最近记录： |