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

This topic created in 761 days ago, the information mentioned may be changed or developed.

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

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

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

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

TLS

代理

直连

11 replies • 2024-05-13 01:53:38 +08:00

Akitora

May 11, 2024

ShadowTLS?

KirbySD

May 11, 2024

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

8520ccc

May 11, 2024 via iPhone

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

maybeonly

May 11, 2024

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

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

povsister

May 11, 2024 via iPhone

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

retanoj

May 11, 2024

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

retanoj

May 11, 2024

@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

May 11, 2024 via iPhone

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

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

qilme

May 11, 2024 via Android

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

povsister

May 11, 2024 via iPhone

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

LGA1150

May 13, 2024 via Android

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