我正在尝试使用 Boost ASIO 编写一个简单的 HTTP/HTTPS 代理。HTTP 工作正常，但我在使用 HTTPS 时遇到了一些问题。作为记录，这是一个本地代理。无论如何，这里是一个事务如何与我的设置一起工作的示例。
浏览器请求 Google.com
我对浏览器撒谎并告诉它转到 127.0.0.1:443
浏览器套接字连接到我在 443 上的本地服务器
我尝试读取标头以便进行真正的主机查找并打开第二个上游socket 所以我可以简单地转发请求。
这是事情立即失败的地方。当我尝试打印传入套接字的标头时，它们似乎已被发出请求的浏览器加密。起初我认为混乱的控制台输出可能只是标题被压缩，但经过一些彻底的测试后，情况并非如此。
所以我想知道是否有人能指出我正确的方向，也许是一些阅读材料，我可以更好地理解这里发生的事情。为什么在与“服务器”（我的代理）的连接甚至完成并有机会与客户端通信之前，标头会立即加密？是临时键吗？我是否需要忽略初始标头并返回一些命令告诉客户端使用什么临时密钥或根本不压缩/加密？非常感谢您的帮助，我已经坚持了一段时间。
HTTPS 通过安全的 SSL 连接传递所有 HTTP 流量、标头和所有内容。这是通过设计来准确防止您尝试执行的操作，这本质上是中间人攻击。为了成功，您必须想出一种方法来破坏 SSL 安全性。
一种方法是提供浏览器将接受的 SSL 证书。浏览器抱怨证书的常见原因有两个：(1) 证书不是由浏览器信任的授权机构签署的；(2) 证书公用名 (CN) 与 URL 主机不匹配。
只要您控制浏览器环境，那么 (1) 很容易通过创建您自己的证书颁发机构(CA) 并将其证书安装为您的操作系统和/或浏览器中受信任的证书来解决。然后在您的代理中提供由您的 CA 签名的证书。您基本上是在告诉浏览器可以信任您的代理提供的证书。
(2) 将更加困难，因为您必须先提供具有正确 CN 的证书，然后才能读取 HTTP 标头以确定浏览器试图访问的主机。此外，除非您已经知道可能被请求的主机，否则您必须动态生成（并签名）匹配的证书。也许您可以为您的代理使用一个 IP 地址池并与您的欺骗 DNS 服务协调，以便您知道应该在哪个连接上提供哪个证书。
通常 HTTPS 代理不是一个好主意。我会劝阻它，因为你真的会违背浏览器的安全性。