Request to implement TLS Client Hello Fragmentation into the Core

[A5DkjGQUZx]

Hi
The new method devised by Iranian guys is being the BIG trend in DPI circumvention. It fragments TLS clients hello packets and send them in random size with random timing so the DPI cannot assemble it and tag the session as white.
I think it can be implemented inside the Xray core as well to be used on Client Side (and even maybe server side for advanced scenarios)

This is the repo of this fascinating project: https://github.com/GFW-knocker/gfw_resist_tls_proxy

THIS IS THE NEXT STEP IN INTERNET FREEDOM...

[wy580477]

Is it similar to this?

#1757

[A5DkjGQUZx]

Is it similar to this?

#1757

The answer is "No" to my understanding.

[lostsoul6]

I can confirm that the mentioned windows python script works in Iran and I can successfully bypass GFW even with servers and cloudflare IPs that are banned in Iran ! I have already requested this feature in v2rayN and v2rayNG but @2dust said we should submit it to Xray-core .

Here is the link of my request : 2dust/v2rayN#3761

it seems that GFW have a limited cache and can't wait for a long time to receive all fragments of the TLS hello client and figure out the SNI and check if it's in the whitelist or not . On top of that , they can't drop all fragmented hello client requests because they are part of the internet and there are some legit usages .

Anyway we think there is something here . would be awesome if we could implement it in Xray-core so there is no need for clients to get involved as most of them don't have the knowledge to set up their clients as such .

Regards ,

[WatchDogsDev]

This is a really smart approach which needs to be added to core. Up voting :)

[us254]

In short, it can be used, but it is not suitable for large-scale promotion. If it attracts the attention of GFW, it will be detected soon

Because normal TLS traffic does not send Client Hello into multiple frames, there is no reasonable explanation, and GFW only needs to detect this to catch it

#1988

[A5DkjGQUZx]

rrouzbeh is working on this:
https://github.com/rrouzbeh/Xray-core

main...rrouzbeh:Xray-core:main

[xqzr]

#2002

[A5DkjGQUZx]

#2002

The mentioned method focuses on just TLS Hello not all TCP packets...

[RPRX]

我的顾虑如下：

1. 检测它过于容易，Xray 加它必定会加速检测机制的部署，或许很快就会导致谁都没得用 Adding the idea of confusing GTW #1996 (comment)
2. 客户端想开就开，那么当它被稳定检测、封锁后，有意无意间就会祸害服务端（Xray 不开放修改浏览器指纹是类似的道理）

我看到 GFW-knocker/gfw_resist_tls_proxy#59 (comment) 提到它的主要用途是过 CF，那么我们可以只给 WebSocket + TLS 添加分割 TLS Client Hello 的功能（WSS is deprecated anyway），满足伊朗的需求，不影响其它 TLS。格式为 path 参数，类似于 #375

CC @GFW-knocker @rrouzbeh @free-the-internet

[lostsoul6]

@RPRX

If this is added to XRAY-CORE , it would be useful for servers with IPs that GFW has blocked . There is no need to use this on servers that have clean IPs . Only usage would be when servers are blocked and we hide IP behind Cloudflare . This mechanism can bypass the limitations that Iran has placed on Cloudflare . It would be nice if we have the option to do it on the server side rather than involving clients to install scripts on their system.

Also I have another question for you . Is there a way to limit the number of connections in XRAY ? I noticed even when one client is connected to the server , X-UI shows like 200 connections . I understand that XRAY is a proxy but it would be nice if there was a way to make it like OCSERV where one connection does the tunneling . In Iran GFW is configured to detect high number of connections to a server and they block it soon .

[free-the-internet]

我的顾虑如下：

1. 检测它过于容易，Xray 加它必定会加速检测机制的部署，或许很快就会导致谁都没得用 Adding the idea of confusing GTW #1996 (comment)
2. 客户端想开就开，那么当它被稳定检测、封锁后，有意无意间就会祸害服务端（Xray 不开放修改浏览器指纹是类似的道理）

我看到 GFW-knocker/gfw_resist_tls_proxy#59 (comment) 提到它的主要用途是过 CF，那么我们可以只给 WebSocket + TLS 添加分割 TLS Client Hello 的功能（WSS is deprecated anyway），满足伊朗的需求，不影响其它 TLS。格式为 path 参数，类似于 #375

CC @GFW-knocker @rrouzbeh @free-the-internet

@RPRX
We already observed that firewall in Russia drops the buffer if there is duplicate or if a few other criteria is met. So, I agree with you that GFW can react fast and drop all the fragmented packet that it can't assemble.

However, an option to only list the hosts that need to be fragmented can be a good solution. Similar to object for routing, for example.

[A5DkjGQUZx]

我的顾虑如下：

1. 检测它过于容易，Xray 加它必定会加速检测机制的部署，或许很快就会导致谁都没得用 Adding the idea of confusing GTW #1996 (comment)
2. 客户端想开就开，那么当它被稳定检测、封锁后，有意无意间就会祸害服务端（Xray 不开放修改浏览器指纹是类似的道理）

我看到 GFW-knocker/gfw_resist_tls_proxy#59 (comment) 提到它的主要用途是过 CF，那么我们可以只给 WebSocket + TLS 添加分割 TLS Client Hello 的功能（WSS is deprecated anyway），满足伊朗的需求，不影响其它 TLS。格式为 path 参数，类似于 #375

CC @GFW-knocker @rrouzbeh @free-the-internet

This

我的顾虑如下：

1. 检测它过于容易，Xray 加它必定会加速检测机制的部署，或许很快就会导致谁都没得用 Adding the idea of confusing GTW #1996 (comment)
2. 客户端想开就开，那么当它被稳定检测、封锁后，有意无意间就会祸害服务端（Xray 不开放修改浏览器指纹是类似的道理）

我看到 GFW-knocker/gfw_resist_tls_proxy#59 (comment) 提到它的主要用途是过 CF，那么我们可以只给 WebSocket + TLS 添加分割 TLS Client Hello 的功能（WSS is deprecated anyway），满足伊朗的需求，不影响其它 TLS。格式为 path 参数，类似于 #375
CC @GFW-knocker @rrouzbeh @free-the-internet

@RPRX We already observed that firewall in Russia drops the buffer if there is duplicate or if a few other criteria is met. So, I agree with you that GFW can react fast and drop all the fragmented packet that it can't assemble.

However, an option to only list the hosts that need to be fragmented can be a good solution. Similar to object for routing, for example.

I do agree. The core can be even used for fragmenting TLS Hello for some sites such as Youtube (e.g. in Iran it is not blocked by IP but by tls host and domain). So an outgoing Freedom for a specific rule can be used with a specific transport option that fragments TLS hello...
Sounds to me reasonable enough to make it an available feature in the Core.

[lilcheti]

Ok so i created this telegram group https://t.me/howisuconnected to discuss about how we are connected on each isp

[yuhan6665]

Merged