RPRX

并且 REALITY 的 Golang 客户端实现基于 uTLS 的浏览器指纹，所以无法用 Golang TLS 指纹 VLESS 分享链接标准中，TLS 默认也是 Chrome 指纹：https://github.com/XTLS/Xray-core/discussions/716 *Moreover, REALITY's Go client implementation relies on browser fingerprinting via uTLS, so Go TLS fingerprinting...

这些代理协议的历史是这样的，2021 年初的 Qv 开发群，我说既然 XTLS 是拼接别的 TLS 进来，那么可以“反向拼接”：先与目标网站握手，再把代理流量拼后面，让 GFW 以为在访问白名单网站，@xiaokangwang 说用于握手的 TLS 流量也可以由外部程序发起 但后来我们都没开发这样的协议，直至 2022 年中出现了 ShadowTLS，就是干的这件事，半年后我写 REALITY 时选择了另一个路线 看描述 TLSMirror 的拼接部分更像是初始版本的 ShadowTLS，它无法防御重定向等攻击，所以才有了 v2v3，针对这类协议的重定向攻击指的是，服务端为了区分连接是否由代理协议客户端提供，客户端需要先提供身份证明，但是如果身份证明不够隐蔽，比如说直接从某个 TLS record 开始换成自己的 AEAD，攻击者可以把某个连接导到真正的网站，并观察会不会异常断开，以此来识别协议 仅看描述而言，当前版本的 TLSMirror...

补充：当时没直接写 ShadowTLS 这种东西，以及后来 REALITY 选择另一个路线的一个原因是，ShadowTLS 这样的路线需要使用外部的加密方案，但是我不是很想自创一种加密，所以干脆直接复用 TLS 的加密方案，这也是与 Cloak 等其它方案最大的区别 我觉得 REALITY 这个路线的优点是显而易见的，那就是直接获得了 TLS 级别的加密水平，比如 TLSv1.3 只保留了最安全的加密方式，有前向安全，最近的抗量子也可以直接上，此外 REALITY 的认证部分采用了公私钥的设计，仅拿到客户端配置无法识别、解密流量 流量整形的部分可以交给内层比如 Vision，长远来看的话也可以由 REALITY 的 TLSv1.3 padding 直接完成 https://github.com/net4people/bbs/issues/481#issuecomment-2984668432 --- *Additional note:...

原始 TLS 流量还会持续进行传输，我觉得这个挺有意思的，@wkrp 提出原始 TLS 连接可能会关闭，我觉得这个不是大问题，以及服务端识别客户端身份也不成问题，最关键的问题在于我刚注意到 @xiaokangwang 也写道，当前版本的 TLSMirror 没有防御重定向攻击，但当开始处理该问题时，就会发现客户端必须隐蔽地提供身份证明，所以 ShadowTLS 后来才会变成“修改 TLS 握手信息”的样子，或者其实可以使用另一条连接来告知服务端哪些连接是代理，但需要借助别的东西，使得 TLSMirror 自身无法成为“完备的代理” *The original TLS traffic will continue to be transmitted, which I find quite interesting....

深入分析“原始 TLS 流量还会持续进行传输”，它虽然有趣，但会造成一个安全问题是，原始 TLS 的 AEAD 并不包含对 TLSMirror 那些 records 的顺序保护，也就是说，基于目前的设计描述，可以想象如果攻击者只把 TLSMirror 的 records 抽离出来，该 TLS 连接并不会异常断开（当然也可以多开一条连接来传递顺序信息，但更复杂了）。此外原始 TLS 是正常断开还是异常断开只有自身知道，我前面说“原始 TLS 连接可能会关闭，我觉得这个不是大问题”是因为我们完全可以在原始 TLS 正常断开后继续传输流量，但是如果攻击者插入一个 TLS record 使它异常断开，而我们认为它是正常断开并继续传输流量，就会露馅。 并且我细想了一下，“原始 TLS 流量还会持续进行传输”也存在流量整形上的问题，因为在它常规的流量形状外面再加别的东西，就很容易偏离它常规的流量形状。更优解似乎是直接把被代理流量整形为目标网站常规的流量形状、替换掉原始 TLS，效率也更高。...

> 对 其实这个调换原流量和插入流量的顺序问题的解决方法已经想好了，不过还没实现。当然这个需要再单独加一个功能来解决，尽管方法并不是单独再开一个连接。在首个加密帧被插入后的每个加密TLS帧的最后8个字节的加密数据都会被根据发送端的序列号被再原地加密一次。在接收端都会先根据接收端的序列号进行原地解密后再尝试解密或转发到原链接。 如果采用这种方式则需要额外的字节来传递认证信息，比如 AEAD 会增加 16 字节的长度，从而破坏原始的流量形状，虽然不及 ShadowTLSv3 给关键 records 加了四字节导致被 Aparecium 宣告“dead”那么严重。其实我觉得既然都有一条主控连接了，直接用它来传递主控信息就可以，缺点是当这条主控连接被 GFW 干扰时会影响其它所有连接。 当然产生这个问题的根本原因还是 TLSMirror 希望保持原始 TLS 连接的传输，这也是它与其它类似代理协议的最大不同之处，但如前所述，这样做其实存在一些流量整形上的问题，如果细想的话不一定优于其它类似代理协议的“扔掉原始 TLS 连接”。 *If this approach is adopted, additional bytes...

> [《Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes》](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting)'s Table 3 该论文在草案阶段时我看过并提出了两个主要问题，但并没有被采纳，一是该论文的被代理流量均为 TLSv1.2，而现实世界中大多数流量为 TLSv1.3，会少一次握手从而少一些流量特征，据第一作者称针对内层 TLSv1.3 的检测效果不佳，所以选择了 TLSv1.2 另一个问题是 table 3 并没有放出通用性的 c1 模型检测 XTLS Vision 的数据，而是用一个有针对性逆向 Vision 的 c2 模型去检测（如果对每个协议都做一个针对性的模型，那当然能提高准确度），使得最后的...

> 我的设计是把序列认证信息叠加于原有的数据帧中不改变长度 ~~这是已经实现的吗，因为从信息论的角度来说似乎无法实现~~ > *My design is to overlay the sequence authentication information onto the original data frame without changing the length.* *~~Is this already implemented? Because from an information...

> 然后，虽然自己不能检测这个信息，但是如果错误的话就会直接让被转发站检测到校验失败进行相应的处理。 I see，大概猜到比如生成一个序列用于 XOR，代理协议服务端只能还原但自己检测不了，我需要思考一下这样设计是否存在问题 > *Then, although it cannot detect this information itself, if there is an error, the forwarded station will directly detect the verification failure and take...

比如说数据的发送序列是这样的，real 代表原始 TLS 的包，fake 代表 TLSMirror 的包： ``` real real fake real fake real... ``` 从第三个包开始叠上 XOR，为了避免两个相邻包叠上的数据重复，可以是单调递增，比如 1 2 3 4 5 6 7 8 9... 这样做有一个小问题是，由于代理协议服务端只能还原但自己检测不了，会出现如果攻击者改了第四个包（real），但在时间差内第五个包（fake）仍被代理协议服务端正常解密的情况，不过这并非 XOR 带来的问题，而是同时传输两个连接时固有的问题，等待网站服务端一小段时间即可，但这样会引入延迟，~~或者干脆就不管，等 GFW...