Customization of the initial packet flow

[artoor32]

The current padding mechanism gets detected and blocked when the Iranian gfw enforces restrictions. In our tests, anytls and restls using their padding mechanisms showed greater resistance to TLS-in-TLS detection. However, the Iranian gfw enforces speed throttling based on TLS fingerprints, and uTLS has not updated the fingerprints it uses for a long time. Is it possible to implement a similar padding mechanism in naive?

[klzgrad]

their padding mechanisms

What kind of padding mechanism is detected and what is not? Is this clearly known?

[artoor32]

In 2022, when xtls-rprx-vision was blocked, I began testing various protocols. Hard-coded paddings used in protocols like shadowsocks2022 and naive cannot fully prevent detection they only make it harder. According to reports, the Iranian gfw currently inspects the first few kilobytes of each connection for every ip:port tuple. The first attempt to address this issue was vless seed, but unfortunately it has not been completed even after two years. The restls protocol, using a feature called script, allows defining different padding per server, and anytls supports configurable padding definitions

Related topics:
anytls docs
restls script
vless seed: #3260 #5102

[klzgrad]

What do you mean hard-coded paddings? Naiveproxy does not use a hard-coded padding.

Edit:

showed greater resistance

The resistance is relative? Do you have a large number of data points to show this correlation?

My point is precisely to not allow customization of the padding because customization is in itself a form of hardcode which nobody is knowledgeable enough to design.

What is the model of padding detection in Iran? Does the same padding used in anytls and restls get detected after a period of time so you can quickly change it? Or is the point to use different padding per server to spread the risks?

Edit2:

If you like, I can make some options for you to experiment. But not in the form of padding customization.

[artoor32]

I have 20 servers with about 400 TB/month total traffic. When I use protocols without padding and the firewall is active, a server IP gets blocked after about two hours. Using naive with padding extends survival to several days — a clear improvement over no padding — but the IP still eventually gets blocked. When I use the script feature in restls or anytls with my custom padding scheme applied to the first 10–15 packets, I haven’t had any server IPs blocked so far; however, because the tls fingerprints are old, we see many timeouts and connection drops. According to a paper, 'Random padding is not the final word when it comes to obfuscating patterns within packet size sequences,' and naive has about a 30% chance of being blocked. It’s possible that the survival of restls and anytls is due to their customized post-handshake mechanisms

[artoor32]

Restls-Script has the following capabilities:

1. Specify the length of the nth packet; if the data to be sent exceeds the length specified in the script, the data will be truncated; if the data to be sent is less than the length specified in the script, padding will be added.
2. Request the peer to send m responses after the peer receiving a certain packet.

With these two capabilities, we can control the length and traffic pattern of Restls in the inner TLS handshake phase in an extremely flexible manner, thereby completely disrupting the "TLS in TLS" and other characteristics.
Each user can write their own script, making Restls have no unified characteristics and greatly reducing the threat of passive traffic analysis.

Is it possible to add this mechanism to naive?

[klzgrad]

I refrain from simply implementing specifying nth packet length before seeing the full experimental causality in the TLS classifiers.

Is it because random padding shows too much entropy? I can make an option to test this.

I can also make per connection preamble, which avoids explicit specification of packet lengths.

But I didn't implement these because no experiments showed their usefulness. So to add these behaviors I need experiments, which you can try out.

[klzgrad]

Connection preamble: for your server example.com, connection preamble means to create regular HTTP requests for https://example.com/, https://example.com/favicon.ico, https://example.com/page.css, etc before doing traffic tunnelling. I thought this would be more organic than creating artificial padding lengths.

[artoor32]

I think preamble is a good feature and worth trying. it might be better than the fake responses used in restls. both approaches alter the initial packet pattern and preamble produces more realistic behavior. preamble idea could potentially address the challenge discussed in this paper.

I should add that when we use xhttp with split upstream and downstream when upload and download streams run over different IPs (without padding), we haven't observed IP blocking so far. I believe combining xhttp + naive, or using a dedicated upload/download splitter, could be a good option

[artoor32]

I plan to work on developing an app that combines naive with xray. The goal is not just for splitting upload/download, it could also provide features like routing rules and user management.