RPRX

> 由于 TLSMirror 已经选择了在转发 TLS alert 后不继续使用该连接 需要指出的是，上面的所有攻防推导都已经基于这个前提，否则会出现攻击者改了 real 包但 TLSMirror 还在继续传输 fake 包的情况 > *Since TLSMirror has chosen not to continue using the connection after forwarding the TLS alert*...

> 会出现如果攻击者改了第四个包（real），但在时间差内第五个包（fake）仍被代理协议服务端正常解密的情况 我想了一下这个问题还有另一个解法：在第五个 fake 包内对上一个 fake 包后所有的 real 包进行额外认证，~~不会违反信息论~~ 至此，最核心的问题还是“原始 TLS 连接有价值”和“代理可用性”的矛盾，基于当前的设计，代理可用性取决于外部程序的连接需求（一个解法是使用尽可能多的境外 IP 搭建尽可能多的端口转发，或者 IPv6 也不是不行），而如果我们倾向于自己发起原始 TLS 连接，则数据无价值、其实可以被丢弃，就失去了 TLSMirror 最大的创新之处（不过至少还是优于 ShadowTLS 系列）。 > *A situation may arise where the attacker...

但仔细想想如果包含“对 real 包认证”的 fake 包到达及时，仍然可以扔掉正常的 TLS alert、继续传输流量，从而解决代理可用性的问题 ~~不过似乎还有一些边缘情况，比如常规的流量断开 pattern（不活跃、max 时间等）、fake 包应当多及时等，有点烧脑，先不想了~~ *But think about it carefully. If a fake packet containing “authentication for the real packet” arrives in time, you...

> 在第五个 fake 包内对上一个 fake 包后所有的 real 包进行额外认证 `hash(hash+real)` 不断循环就行，这样就能知道流量有没有被 GFW 篡改，从而避开异常 TLS alert，成为“继续传输流量”的基础 > *perform additional authentication on all real packets after the previous fake packet in the fake...

这样的话比 ShadowTLS 更优，只剩三个小问题，一是传输初始认证信息需要别的通道，二是加密机制一般，三是目标是结合外部程序 *This is better than ShadowTLS, with only three minor issues remaining. First, a separate channel is required to transmit the initial authentication information. Second, the encryption mechanism...

> 实际上实现的版本并没有丢弃"正常"的TLSAlert或者其他的正常连接关闭消息的功能。就是普普通通的加密水印一下数据包。毕竟区分是不是正常的Alert容易出问题，不如先保守一点保证协议没办法被识别，足够易用，再想别的。 我觉得挺好区分是不是正常的 alert，因为基本上当有人篡改数据时才会异常 alert 不过我想了下防止包被调换位置确实需要加密，因为简单的 XOR 会容易受到攻击 但这样还是没有解决攻击者可以利用时间差来发现其实有两个检测端点，从而识别协议的风险，所以 fake 包里附带认证是必要的 这样也可以在有价值的 TLS 连接关闭后继续传输信息，因为 TLSMirror 的特性要利用外部程序发起的有价值的 TLS 连接才比较有意义，而它们是不可控的。如果要用 v2ray 自己发起连接，就不太有必要搞这种两个 TLS 同时传输这么麻烦，直接流量整形就行了。并且 TLS 握手基本上没有限制，但 HTTP 请求会有风控，无意义请求数多了可能就会被目标网站拒绝。 --- *I think it's...

@Fangliding 如果不认证，攻击者可以利用两个检测端点的时间差来实现改了 real 包，但 fake 包仍被正常接收、处理 不过我想了下，如果在 fake 包里包含对前面的 real 包的认证，但攻击者给这个 fake 包加延迟，也会有点问题，~~又烧脑了~~ 但是审查者通过篡改 TLS record 来确认自己的怀疑，我觉得目前不太可能这样干，除非哪天大家都用 TLSMirror 或~~形势严峻~~ --- *If not authenticated, an attacker can exploit the time difference...

> > [《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...

诡辩罢了，一个很简单的问题：**由于 pin 证书对于 TLS 是可选的，你如何保证所有实现都强制 pin 证书？该用法有没有占万分之一？** REALITY 是采用协商出的“认证密钥”对“随机证书”进行签名以验证服务端的身份，**相较于 pin 证书，该过程为强制的，占 100%** 这与 Web-Panel 是否应从源头禁止公网明文 HTTP 是类似的问题，但更严重，因为 pin 证书的概率比不使用明文 HTTP 的概率低得多 --- *That's just sophistry. A very simple question: **Since...

并且对于 TLS 而言，pin 证书在实践上存在一些阻碍，因为证书经常更换、不一定由谁签发，如果是直连自己的服务器那还可以预测，而如果是 CDN 那就五花八门、不定什么时候就换了。虽然套 CDN 会不可避免地使用 TLS，但若要防止 CDN 偷窥通信内容会启用 VLESS Encryption 这样的可靠加密，从而同时防止了 GFW 对内层 TLS 进行 MITM，本质上还是对单纯 TLS 的不信任。 一个相对有意义的改变可能是，比如说对 Xray-core 而言，内置所有的根证书而不信赖系统根证书，但还是那个问题，我只能确保 Xray-core 这样做但管不到别的代理客户端，此外如果有任意一个 CA 与 GFW 合作签发假证书（CNNIC...