An active attack on XTLS under origin mode

[nametoolong]

This attack is beyond the original threat model of XTLS. This issue is to discuss XTLS usage against more aggressive local adversaries like corporate firewalls.

There is an intrusive way to detect whether an encrypted TLS alert is close_notify: injecting binary garbage into the TCP connection. If an endpoint ignores the binary garbage, then it must have received a close_notify alert. XTLS parses the record but is not aware of the encrypted close_notify, so an active attacker can tell apart XTLS from other TLS stacks.

1. The user starts a huge download over HTTPS. Both Firefox and curl sends close_notify early during a download, so the attacker can begin after seeing the first 19-byte encrypted data.

2. The attacker forges TLS records and sends them to the XTLS server. XTLS forwards them to the actual server, who ignores them silently.

3. The attacker forges malformed TLS records. XTLS closes the connection immediately.

4. The attacker can now be sure of the existence of XTLS.

This attack is unlikely to be adopted by the GFW due to its potentially destructive effects. However, corporate networks might occasionally be aggressive enough to disrupt all TLS traffic. Direct mode is not a permanent solution: the mismatch between Client Hello extensions and the actual behavior easily spots a XTLS user.

[RPRX]

感谢提供一个新颖的思路：某些情况下 TLS 会发送 Alert 但不关闭 TCP 连接。不过这种方式受到的限制也比较明显：

1. TLSv1.3 后续指令/数据均采用 data record 的标识符 23（即使是 Alert），且 TLSv1.3 允许 padding，这些都会干扰判断
2. 如标题所述，这种方式只针对 Origin 模式；如内容所述，Firefox 和 curl 才会受影响（但不确定其它 TLS 应用的行为）
3. 如内容所述，这种方式对 TLS 连接是破坏性的，只有公司网络敢这么干，这里的问题是：找出 XTLS Origin 的现实意义
4. 即使不考虑破坏性，仍存在一个误报率的问题：由于 TLS 的应用广泛且复杂，是否某些 TLS 实现/网络因素会被误报？

这里顺便说一下，计划中 Origin 会被废弃（也几乎没人在用了），主要是因为：

1. Origin 是最初的探索，逐渐发现仅去掉加解密只能提升有限的性能，Direct 的 ReadV 和 Splice 甚至 Sockmap 才是大杀器
2. Origin 的思路是将现有的 data record 作为自己的 data record，辅以严格的读写过滤处理和状态控制，心智负担比较重
3. Direct 其实并不需要魔改 TLS 库就可以实现，它不需要读过滤，甚至传输 TLSv1.3 时连写过滤都不需要，非常简洁、高效

关于 issue 中的最后一句话，麻烦展开叙述一下。另外，XTLS 正在研究引入 uTLS，即客户端指纹伪造功能。

[RPRX]

补充：Origin 严格的写过滤预计会被应用到 Direct 对 TLSv1.2 的传输中。

[nametoolong]

即使不考虑破坏性，仍存在一个误报率的问题：由于 TLS 的应用广泛且复杂，是否某些 TLS 实现/网络因素会被误报？

TLS 1.3 mandates connection closure upon error. So an RFC-conforming implementation will never trigger a false positive. False negatives are unavoidable.

关于 issue 中的最后一句话，麻烦展开叙述一下。

For example, the attacker can initiate a renegotiation when the upper-layer protocol is TLS 1.2 and XTLS is running in Direct mode (no read filtering). The renegotiation will eventually fail but is enough to leak a huge amount of information. The current implementation of write filtering does not prevent this because close_notify is non-fatal. TLS 1.2 has so many obscure extensions that the behavioral difference is difficult to eliminate.

Even under TLS 1.3, a corner case exists: when the upper-layer negotiates TLS_AES_128_CCM_8_SHA256, protected alert records will be 11 bytes long instead of 19 bytes. This is impossible for other ciphersuites. Few applications (mostly IoT devices) use that ciphersuite though. IMHO the list of possible behavior mismatches will only be longer as people try hard to add esoteric new features into TLS 1.3.

[nametoolong]

I don't think the attacks I've described are practical though. Exploiting the difference between fatal and non-fatal alerts needs precise timing (leveraging the delay between close_notify and TCP reset) which contradicts the threat model. Also, Xray's prominent use cases rarely cover IoT devices.

[yuhan6665]

Thanks for your post. Should be fixed in https://github.com/XTLS/Xray-core/pull/1235

[RPRX]

旧版 XTLS 早已被弃用，新版 XTLS，即 XTLS Vision 仅支持内层 TLSv1.3 非 TLS_AES_128_CCM_8_SHA256 裸奔，谢谢你提到它