[Russia] Censor has a new method of blocking

[hyperion-cs]

Problem

A few weeks ago, a new method of blocking (especially on mobile networks) was introduced in Russia by the censor.
It works as follows. So, if:

1. The client connects to the server via TCP using HTTPS and TLS 1.3 (for example, VLESS/Reality actually mimics HTTPS with TLS 1.3);
2. The IP address of the server is “suspicious” (it is located outside ⚠️ (i.e. not in Russia), is part of the subnet AS which is owned by foreign data centers like Hetzner, Digital Ocean, etc.);
3. Within one TCP connection (not within one HTTP request/response - this is important) the data size received from the server to the client is more than ≈15-20KB (the value varies depending on the provider) — the MAIN thing.

This connection is "frozen" (i.e. TCP packets from the server within this connection stop arriving after the specified limit on the size of transmitted data has been reached). It is curious to note that, as a rule, the censor (under the pretence of a response from the server) does not send, for example, an RST packet - instead, it simply “freezes” the TCP connection (from the client's point of view), and thus the client simply waits for an error on the timeout of waiting for a response from the server and everything stops working.

IMPORTANT: It doesn't matter whether it's "legitimate" HTTPS traffic or whether someone is mimicking it. They don't pay attention to that now.

Do I have these limitations?

You can check your “home” ISP with the RU :: TCP 16-20 checker from this repository. Works right from your browser, VPN should be disabled during the check.

Notes

The good news is that if you fragment the responses from the server into several ≈15-20KB data bundles (if it is large enough) in different TCP connections, everything will work fine. It is important not to confuse this with fragmentation of TCP packets within one connection or splitting of transmitted data into several HTTP requests/responses (in one connection) - this is different and it won't help.

Yes, it will work noticeably slower than a single connection (especially if we're going to upload/download a large file). For example, it would take ~2560 TCP connections to download a 50MB file - that's a lot and quite suspicious.

---

upd1: TLS 1.2 is also blocked (sometimes there is a different data size limit per TCP connection).

upd2: At the moment it seems that only SSH/sFTP + and sometimes RDP (both on any ports) work within TCP without limitations. Including random data transfer over TCP (without TLS, etc., in raw form) is also limited. It's possible that there are other things within TCP that would work without limitations, I'm not exactly sure about that.

upd3.: Censor has a whitelist (based on SNI in the TLS handshake and possibly an HTTP Host header if plain HTTP is used), for more details, including some subset of that list, see here. For example, this can be used as SNI/dest in xray/vless+reality (with xtls-rprx-vision) and it will work.

upd4.: ❗️Censor has also started to apply a whitelist based on the CIDR (IP subnets) of the destination servers. In this case, circumvention is extremely difficult (as a rule, an intermediate node with an IP from the whitelist is required).

upd5.: In fact, the censor typically freezes the connection after 25 packets have been sent in either direction (incoming/outgoing). This applies to both tcp and udp. On average, this equates to approximately 16 KB of payload.

Related links

• https://blog.cloudflare.com/russian-internet-users-are-unable-to-access-the-open-internet/
• https://hyperion-cs.github.io/dpi-checkers/ru/tcp-16-20/
• BurstObservatory: add option to set http method for burst check XTLS/Xray-core#4835 (comment)
• [feature request] XHTTP Support packet down & retransmission XTLS/Xray-core#4846
• https://ntc.party/t/09062025-%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8F-%D0%BF%D0%BE-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B5-cloudflare-ovh-hetzner-digitalocean/17013

[hyperion-cs]

For a possible solution, see here.

[bmixonba]

@hyperion-cs by fragment, do you mean fragmentation at the IP layer?

[hyperion-cs]

@bmixonba Not really. As part of fragmentation at the IP layer, you can transmit payload from the same TCP connection (in different IP packets). My point is that the payload that was planned to be transmitted in one TCP connection can be split into several TCP connections. Obviously, though, there will be different IP packets for different TCP connections. But this is just a consequence.

[bmixonba]

Interesting. Thank you for the prompt reply. Do you know if either IP fragmentation or TCP segmentation are able to bypass the censor or does it perform reassembly and/or block such packets?

[hyperion-cs]

@bmixonba My experiments show that simply fragmenting TCP/IP packets doesn't help in the described case (because even if you do that, the censor can calculate the total size of transmitted data in the TCP connection - each TCP/IP fragment has everything it needs to account for it, no matter how big it is).

[bmixonba]

Makes sense. Do you know if this behavior is consistent for different providers, e.g., Tele2, Rostelcom, DOM.ru?

[hyperion-cs]

@bmixonba As far as I know, if the provider has this limitation, the behavior differs by the limit of transferred data (but all of them have it in the range of ≈15-20KB). Otherwise, everything seems to be the same.

However, if the question was: do all telecom operators have this limitation applied? The answer is: no, not all of them. Mostly mobile operators (including t2, Megafon, Beeline, Yota, MTS), but it also depends on the region.

[wallpunch]

A few thoughts:

Are all other TCP protocols to those IPs blocked outright? What about UDP?

Is it possible to avoid the blocking by pausing the TCP connection for some time? Like send 10kb, wait 10 minutes but don't close the connection, then send 10kb more.

In theory you could still utilize full bandwidth even with fragmentation by splitting the traffic across a large enough pool of parallel connections. But that would be so conspicuous it couldn't possibly work for long.

[hyperion-cs]

@wallpunch

• 1.1: At the moment it seems that only SSH/sFTP + and sometimes RDP (both on any ports) work within TCP without limitations. Including random data transfer over TCP (without TLS, etc., in raw form) is also limited. It's possible that there are other things within TCP that would work without limitations, I'm not exactly sure about that;
• 1.2: When attempting to use UDP, on average, there is a complete blocking of access to the server for N minutes (about 10 minutes). This also looks like freezing the connection;
• 2: Tested this scenario yesterday. I did not get any positive results (i.e. there seems to be no time window (or something similar) to limit the amount of data within a one TCP connection);
• 3: True, and such an idea I proposed for Reality, however, it was rejected (which is generally fair).

[NilovDir]

• 1.1: At the moment it seems that only SSH/sFTP + and sometimes RDP (both on any ports) work within TCP without limitations. Including random data transfer over TCP (without TLS, etc., in raw form) is also limited. It's possible that there are other things within TCP that would work without limitations, I'm not exactly sure about that;

Roskomnadzor puts so much effort into blocking everything and anything. But the problem can be solved by setting up an SSH tunnel. For example:

PuTTY.exe -ssh root@100.100.100.100 -P 22 -pw 12345678 -D 1080

[hyperion-cs]

@NilovDir it's true, this option works so far. Moreover, you can add something like tun2socks (or use software from the xray ecosystem) to this to create a VPN tunnel and route its traffic to this SSH tunnel so that client applications don't have to specify this SOCKS[port 1080] manually (also, as we know, many applications just don't have this option). You can also design this as a separate intermediate node (for clients), or use out-of-the-box software for VPN-over-SSH — it exists.

However, I find this option not very good:

• It is very easy for a censor to block (or extremely restrict) SSH, since it has a clear fingerprint;
• Many SSH connections to the same server is suspicious, isn't it?
• Transferring large amounts of data via SSH is also suspicious (although it can be partially justified by masquerading as sFTP use, i.e. downloading large files).

In short, promoting this method to the masses will most likely lead to blocking/limits for SSH operation.

[Ysery]

@hyperion-cs I agree with all the points. However, if you’re using the solution solely for personal use, there’s no need to look for alternative options. For example, you wouldn’t need to spend anything on setting up a pair of VPSs (one in Russia and one in Europe).

[hyperion-cs]

@Ysery In such a case, this option better not be mentioned in public sources (which is of course also bad), or it will certainly become popular. In short, I would assume that other options should be researched.