请教各类代理情况下, tcp 连接是由谁建立和维持的, 能否保证数据安全性

[kyonn]

将代理流量分为以下几种情况:

1. 浏览器设置代理, 代理客户端流量走直连.
2. 浏览器设置代理, 代理客户端流量走远端服务器.
3. fakeip 方案的透明代理, 浏览器向 fakeip 发起 tcp 连接.

以下是我的理解; 针对情况 1/2, 浏览器跟代理客户端都是纯粹的 socks 通信, 所有 tcp 连接建立和维持, 包括 tls 握手都是由代理完成的. 1/2 的区别是由本机的代理客户端完成,, 还是远端的代理服务器完成.

针对情况 3, 本机浏览器直接建立了 tcp 连接, 完成 tls 握手, 但由于目标是 fake-ip, 因此 tcp 连接被代理客户端或远端服务器(取决于走直连还是远端)偷梁换柱, 修改报文, 以实现数据正确达到本机浏览器. 但是具体怎么个修改方法比较疑惑.

假设是直连的情况, fakeip 的模式下, 本机代理是重新建了个 tcp 连接, 然后把内容转发给本机浏览器? 还是只是修改了报文里的源 IP 之类的信息, 协助建立连接?

假设是走远端代理的情况, faeip 模式下, 远端代理是重新建了个 tcp 连接, 然后把内容转发给本机代理, 最后再转发给本机浏览器? 还是说只是偷换了本机浏览器的 tcp 连接报文内容, 协助到达目的地?

针对上面 3 种大类, 代理服务器到底能不能截获, 解析 HTTPS 的报文具体内容?如果是代理服务器代为建立连接, 感觉是可以的?

[stephenyin]

这些方式代理服务器都能拿到用户 IP 和 目标 IP ，其他的信息取决于 payload 有没有端到端加密。

情况 3 是代理服务器把用户 IP 绑定在自己的网卡上，然后修改了用户数据包的 checksum 后发出去的。

[kyonn]

@stephenyin 比较好奇这 3 种方式下, 跟目标域名的 tcp 连接都是谁建立的. 换句话说, 本地或远端代理扮演的角色是 HTTP 代理/ssh 代理 还是单纯路由的一环.

[stephenyin]

@kyonn #2 我理解这些情况都是 用户(代理客户端) <-- Socks5 | Trojan --> 代理服务器 <-- TCP | HTTP --> 目标服务器这样工作的，只是透明代理时代理服务器伪装成了用户的 IP 地址。