XTLS
Flow: XTLS-Segaro-Vision
Goals of XTLS-Segaro-Vision Flow:
1-TLS Obfuscation: The flow can obfuscate TLS-in-TLS connections by iterating through the inner handshake and adding padding between iterations. Note that this flow does not add padding at the beginning, middle, or end of inner handshakes; rather, it iterates through the handshake in chunks and obfuscates each handshake with padding.
2-VLESS Header Obfuscation: The flow can obfuscate the VLESS header, specifically the first 32 bytes.
3-Printable Padding: Padding is generated within the range of [32, 126] bytes (ASCII printable characters). After encryption with TLS, the percentage of data that is printable increases compared to prior versions.
4-Fake Packet Transmission: The flow sends fake packets to prevent detection of the inner handshake, accounting for lengths and order of ClientHello or ServerHello packets during transmission and reception.
5-Fake Packet Verification: The flow verifies fake packets to mitigate replay attack occurrences.
6-Chunked Handshake Splitting: Handshakes are split into multiple padded chunks, minimizing detection by analytics through initial packet sizes or search for TLS-in-TLS algorithms within the encrypted data.
7-Protocol Compatibility: This flow can be utilized with the following protocols: VLESS-TCP-Reality VLESS-H2-Reality VLESS-GRPC-Reality
8-Testing and Efficacy: As you may know, the current Reality version is fully blocked in Iran. After testing this flow for two weeks, I can confirm that it operates effectively.
9-Conflict Avoidance: Importantly, this flow does not conflict with the current Reality version; both can function together seamlessly.
Config :
// ...
"clients": [
{
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"flow": "xtls-segaro-vision"
}
],
"decryption": "none"
},
"streamSettings": {
// ...
"realitySettings": {
// ...
"randPacket": "800-1500",
"splitPacket": "500-900",
"paddingSize": 5,
"subchunkSize": 12
}
},
// ...
Server pr: https://github.com/XTLS/REALITY/pull/9
Not incredibly important, but could multiplexing be used with this new flow control mechanism? I guess being able to be used in conjunction with HTTP/2-based transport caters that, but still...
In fact there is a developing feature to obfuscate TLS connection, and this might make some conflicts https://github.com/XTLS/Xray-core/pull/3260 I think some of ideas in this could be able to be integrated with that
Some parts I think unnecessary like VLESS Header Obfuscation (It's already encrypted, why obfuscate it?) Printable Padding (Our goal is to mimic a normal TLS connection, this looks not in line with purpose)
Not incredibly important, but could multiplexing be used with this new flow control mechanism? I guess being able to be used in conjunction with HTTP/2-based transport caters that, but still...
Not now
In fact there is a developing feature to obfuscate TLS connection, and this might make some conflicts #3260 I think some of ideas in this cloud be able to be integrated with that
Some parts I think unnecessary like VLESS Header Obfuscation (It's already encrypted, why obfuscate it?) Printable Padding (Our goal is to mimic a normal TLS connection, this looks not in line with purpose)
The user UUID and dest site, are set in the firsts bytes, which remains static. This consistency may allow for the GFW to gather multiple packets and potentially recognize repeated patterns in the algorithm
In fact there is a developing feature to obfuscate TLS connection, and this might make some conflicts #3260 I think some of ideas in this cloud be able to be integrated with that Some parts I think unnecessary like VLESS Header Obfuscation (It's already encrypted, why obfuscate it?) Printable Padding (Our goal is to mimic a normal TLS connection, this looks not in line with purpose)
The user UUID and dest site, are set in the firsts bytes, which remains static. This consistency may allow for the GFW to gather multiple packets and potentially recognize repeated patterns in the algorithm
AES has made its byte distribution sufficiently random, and any existing analysis of the TLS is based on time and packet length
I don’t quite get the point. Using a TLS server and then obfuscating the client TLS so that the GFW detects the connection as raw TCP seems counterintuitive. However, the techniques and methods are intriguing and might work like many other unconventional methods.
I don’t quite get the point. Using a TLS server and then obfuscating the client TLS so that the GFW detects the connection as raw TCP seems counterintuitive. However, the techniques and methods are intriguing and might work like many other unconventional methods.
GFW can observe TLS data transmission. Specifically, the data is obfuscated before being encrypted by TLS
I didn't catch, does it will be tls in tls?
I am having difficulty understanding your meaning. Could you please provide more information or clarification?
While in extreme cases like manual inspection, XTLS-Segaro-Vision's fake packets and padding could be effective, this approach may deviate from standard browser behavior and raise suspicion. Additionally, deliberately controlling the percentage of printable characters in the ciphertext disrupts the characteristics of TLS ciphertext, making it questionable whether this can successfully bypass censorship.
@RPRX @yuhan6665 @GFW-knocker
Any thoughts on this? Your insights would be greatly appreciated.
首先很高兴看到有人开发新的 flow，这才是 VLESS 的生命力，我逐条说一下：
1-TLS Obfuscation: The flow can obfuscate TLS-in-TLS connections by iterating through the inner handshake and adding padding between iterations. Note that this flow does not add padding at the beginning, middle, or end of inner handshakes; rather, it iterates through the handshake in chunks and obfuscates each handshake with padding.
2-VLESS Header Obfuscation: The flow can obfuscate the VLESS header, specifically the first 32 bytes.
3-Printable Padding: Padding is generated within the range of [32, 126] bytes (ASCII printable characters). After encryption with TLS, the percentage of data that is printable increases compared to prior versions.
无论明文内容是什么，经过 TLS 加密后都应该呈现出全随机数的样子，所以前三条看起来没有必要
4-Fake Packet Transmission: The flow sends fake packets to prevent detection of the inner handshake, accounting for lengths and order of ClientHello or ServerHello packets during transmission and reception.
这个有用
5-Fake Packet Verification: The flow verifies fake packets to mitigate replay attack occurrences.
没有看懂
6-Chunked Handshake Splitting: Handshakes are split into multiple padded chunks, minimizing detection by analytics through initial packet sizes or search for TLS-in-TLS algorithms within the encrypted data.
这个指的是 inner-handshake？
7-Protocol Compatibility: This flow can be utilized with the following protocols: VLESS-TCP-Reality VLESS-H2-Reality VLESS-GRPC-Reality
其实 Vision Seed 也能开启非裸奔模式以兼容更多场景
8-Testing and Efficacy: As you may know, the current Reality version is fully blocked in Iran. After testing this flow for two weeks, I can confirm that it operates effectively.
我觉得这个 PR 最大的意义就是这个 testing，这表明伊朗 GFW 针对的是无 Seed 的 Vision 的流量特征而非 REALITY？
9-Conflict Avoidance: Importantly, this flow does not conflict with the current Reality version; both can function together seamlessly.
但似乎并不需要这样 https://github.com/XTLS/REALITY/pull/9 改 REALITY 仓库的代码
总体上，去掉没有必要的内容后，这个 PR 其实和 Vision Seed https://github.com/XTLS/Xray-core/pull/3260 高度重合，它已经计划一年多了，很抱歉没有早点推出，~~否则你们应该早就可以通过修改参数来摆脱伊朗 GFW 的封锁，如果真是现有流量特征被针对了的话~~。目前我们希望完善 Vision Seed 以兼容更多需求，可以将这个 PR 里 fake packets 融合进去，如果要加新 flow，我们更希望看到像 Switch 这样的本质性改变。
看起来和我说的差不多 ~~所见略同~~ 假包验证可能说的是如果只是发送随机字节然后服务端滤掉可能会有重放/乱序攻击的问题 所以才要验证 不过这种功能应该是都有的 所以可以不用写出来
假包验证可能说的是如果只是发送随机字节然后服务端滤掉可能会有重放/乱序攻击的问题 所以才要验证 不过这种功能应该是都有的 所以可以不用写出来
没看懂的原因是不知道为什么 TLS 或 REALITY 之上需要这个东西，~~也很好奇这个 PR 具体是如何实现的~~
We are recently pushing https://github.com/XTLS/Xray-core/pull/3260 and doing some experiment with university researchers. Please take a look at it. Since it was meat for pretty much the same purpose, I'd close this one later if no objection. In the future, please consider making smaller pull request and engage with core devs before you implement big changes. Thanks for you effort though.
8-Testing and Efficacy: As you may know, the current Reality version is fully blocked in Iran. After testing this flow for two weeks, I can confirm that it operates effectively.
我觉得这个 PR 最大的意义就是这个 testing，这表明伊朗 GFW 针对的是无 Seed 的 Vision 的流量特征而非 REALITY？
我比较关心这个 @LuckyLuke-a
可以将这个 PR 里 fake packets 融合进去 @RPRX @LuckyLuke-a Is this good idea to have PR only including "Fake Packet Transmission" on existing seed transmission?
