HTTPS多层代理转发方案问询：A→代理B→浏览器端C→服务端D链路实现

核心协议选型 #

• A<->C端到端加密：AES-GCM，基于已有的A的公钥完成密钥协商，全程无明文泄露给B
• B<->C传输层：WebSocket，浏览器原生支持，无需额外依赖
• A<->D端到端TLS：直接复用标准HTTPS/TLS 1.3协议，C仅做报文透传，无法获取TLS会话密钥
• 寻址逻辑：A将目标D的域名/端口加密封装在隧道payload中，由C完成DNS解析和TCP连接建立，B全程无感知

各端实现工具&逻辑 #

A端（虚拟机） #

• 开发工具：可直接用Go/Python基于原有vsocket转发逻辑修改，无需引入重型组件
• 核心逻辑：
  1. 生成随机AES-GCM密钥，用自身私钥签名后发往B，由B转发给C完成密钥协商
  2. 把要发送给D的原始TLS报文、目标D的域名+端口封装后，用协商好的AES密钥加密，通过vsocket发往B
  3. 接收B返回的加密报文，解密后拿到D的响应报文，交给上层应用

B端（宿主机） #

• 开发工具：Node.js/Go实现简单的双端转发服务即可
• 核心逻辑：
  1. 同时监听vsocket连接（对接A）和WebSocket服务端口（对接C），通过唯一连接ID绑定配对的A、C连接
  2. 完全透传两端的流量，不做任何解密、解析操作，所有转发内容均为A<->C的加密密文

C端（浏览器） #

• 开发工具：基于Chrome/Firefox浏览器扩展开发，用原生JS+Web Crypto API实现，无需额外依赖
• 核心逻辑：
  1. 预配置A的公钥，连接B的WebSocket服务后，验签A发来的密钥协商报文，确认AES共享密钥
  2. 解密B发来的报文，提取目标D的域名/端口，调用浏览器扩展的chrome.sockets.tcp（或对应火狐API）发起对D的TCP连接
  3. 透传解密后的原始TLS报文到D，同时把D返回的TLS报文用AES加密后发回B，全程不解析、篡改TLS握手内容

方案合规性验证 #

• B侧无任何明文信息：所有流量均为AES加密密文，无法获取D的地址、A的请求内容，满足要求1
• D侧来源IP为C的IP：TCP连接由C直接发起，D拿到的源IP就是C的公网IP，满足要求2
• 无密钥泄露风险：A和D直接完成TLS握手，C仅做报文透传，无法获取双方协商的TLS会话密钥，符合安全要求

内容的提问来源于stack exchange，提问作者Jonas Metzger