除 IP 黑洞外，「只代理 TLS 握手，在 TLS 会话失效之前直连」是否有可行性

[KirbySD]

RT 。当然我仍然在使用加密代理，仅仅希望讨论一下

前提：
1. 不讨论直连线路质量
2. 不讨论当局根据连接 IP 对你访问的内容浮想联翩的风险(*1)
3. 使用加密 DNS 防止 DNS 污染
4. IP 黑洞等情况仍然代理

*1 加密 DNS 、代理 TLS 握手后理论上只能看到 IP ？

冒出这个想法的原因：
1. 减少发送到代理服务器的流量
2. 减少全流量加解密给移动设备带来的计算开销
3. 代理服务器的 IP 地址通常信誉度较低，导致风控等问题
4. 当局目前似乎倾向于采取 SNI 阻断的方式，而较少采取封禁 IP 地址的方式

[Akitora]

ShadowTLS?

[KirbySD]

@Akitora 似乎区别很大
ShadowTLS 仍然代理所有流量，并且暴露一个伪造的 TLS 握手给审查者
本帖的想法只代理 TLS 握手部分（解决明文 SNI 被阻断的问题）。其余部分为未代理的 HTTPS 流量

[8520ccc]

QUIC 可行 因为支持连接迁移
基于 TCP 的应该都不行，因为无法迁移连接的

[maybeonly]

quic 实际上也不一定可行，看服务端配置/实现
不过，您都 quic 了，目前是没有 sni 阻断的
（ quic 的 sni 是加密的，虽然第三方可以做到直接解密

p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器

[povsister]

你说的这个 tcp 不可行 quic udp 支持 multipath 倒是可以试试
另外，墙目前对于 tls hello 分片是不阻断的，xray freedom 已经提供相应功能
然后 单纯加密 client hello 来说，有 ECH ，倒不用费劲去连接上弄这么多事

[retanoj]

理解一下，OP 是希望
TLS 握手部分 client -> proxy -> target
TLS 正常流量 client -> target
这样？ 前提是 client -> target 这条路得通且相对稳定吧

[retanoj]

@povsister
emmm.. MPTCP 的话
首先 client <-> target 建立 MPTCP ，然后 client -> proxy -> target 建立 MPTCP subflow
或者 client <-> proxy <-> target 建立 MPTCP ，然后 client -> target 建立 MPTCP subflow
而且还得要求 proxy 是个支持 tcp over X 的代理（也许可以直接是个 VPN ？）
最后 client 应用层得有能力控制哪些请求从哪条 subflow 走
有点麻烦啊 :(

[KirbySD]

我理解 TCP 不支持连接迁移，又查阅了一下资料发现之前网传的“pixiv 在打开后断开代理仍然可继续访问一段时间”似乎是得益于 TLS 会话恢复机制？（虽然没有实际抓包看过）
TLS 会话恢复机制不是默认开启的，感觉这条路也行不通
这个想法似乎不太可行

@povsister ECH 特征过于明显，感觉会走上 ESNI 的老路
@retanoj 是的，因此我加了几个限定条件

[qilme]

https://upb-syssec.github.io/blog/2023/record-fragmentation/
关于分片的研究

[povsister]

ECH 特征这个确实没啥办法..
另外，我认为连接状态迁移这个特性在工业环境用的都不多，工业上大多是多通路互为备份
指望个人能依赖这个特性意义不大，何况墙并不是只做 sni 阻断，加之高峰期糟糕的出国线路质量，直连浏览质量也会很差

[LGA1150]

甚至可以只代理 SYN ，后面跑裸流