bbs
bbs copied to clipboard
net4people
[Russia] Censor has a new method of blocking
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:
- 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);
- 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.);
- 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.
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.
Related links
- https://blog.cloudflare.com/russian-internet-users-are-unable-to-access-the-open-internet/
- https://github.com/XTLS/Xray-core/pull/4835#issuecomment-2988824955
- https://github.com/XTLS/Xray-core/issues/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
Any ideas (which would not require additional intermediate nodes)?
@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.
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?
@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).
Makes sense. Do you know if this behavior is consistent for different providers, e.g., Tele2, Rostelcom, DOM.ru?
@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.
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.
@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).
- 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 [email protected] -P 22 -pw 12345678 -D 1080
@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.
@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).
@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.
@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.
I don't think it's going to end well. In any case, Roskomnadzor will find it and fix it. In fact, there is no "good" way to bypass this, any bypass methods are either slow (for example, VPN over DNS) or easily detectable (SSH/SFTP, since these protocols usually do not transfer that much data and the 16-20 Kb limit with normal SSH usage will be unnoticeable).
@Applone, well, it's a cat-and-mouse game. I suggest we solve problems as they arise.
@hyperion-cs, you right, but we really don't have any other options in case, that SSH/SFTP banned, we should look further.
It's better to look for other options with free Internet than without it.
P.S.: RDP already banned.
@Applone well, SSH/SFTP is not the only option to solve the problem (see this issue - you can see some other ways to solve the problem between the lines). That there should be a “safety margin” on the solution is partly true.
Anyway, I suggest we focus on the technical details of the problem here.
I suppose the 20KB cutoff specifically targets circumvention tools. Do you think it's accurate? Like it would be pretty accurate if a real HTTP server like NGINX or Caddy wouldn't be blocked?
Is this blocking happening on all ports (1-65535) or just 443?
Send fake packet woth a lower ttl or wrong checksome (desync) with http header may confuse the censor.
In theory it is possible to improve the scheme with an intermediate server in Russia. As an option to set up a server in Russia as a client/server, then connect to it as a client abroad server, and we already connect to Russia server. Only for all this we need to configure incoming/outgoing rules. I don't have enough knowledge for this.
In theory it is possible to improve the scheme with an intermediate server in Russia. As an option to set up a server in Russia as a client/server, then connect to it as a client abroad server, and we already connect to Russia server. Only for all this we need to configure incoming/outgoing rules. I don't have enough knowledge for this.
How will this help if the server in Russia is in the same conditions when its traffic is filtered?
How will this help if the server in Russia is in the same conditions when its traffic is filtered?
The thing is, the server usually isn't in the same conditions - some datacenters have less network restrictions.
@UjuiUjuMandan,
I suppose the 20KB cutoff specifically targets circumvention tools. Do you think it's accurate? Like it would be pretty accurate if a real HTTP server like NGINX or Caddy wouldn't be blocked?
Is this blocking happening on all ports (1-65535) or just 443?
It's detailed above that this works regardless of the “tool” (i.e., it affects nginx/etc as well), also it's not port dependent.
@Disshell, if I understand you correctly, this could be useful for tracking statistical correlations between connections:
- Client <=> Intermediate Server ( Russia);
- Intermediate server <=> End server (foreign).
But it shouldn't help in real time. In short, it's probably not useful to use it now.
@maoist2009,
Send fake packet woth a lower ttl or wrong checksome (desync) with http header may confuse the censor.
Yeah, that's approximately how things like zapret work. But this would have to be used on the client (well, or on a router on your home network).
In theory it is possible to improve the scheme with an intermediate server in Russia. As an option to set up a server in Russia as a client/server, then connect to it as a client abroad server, and we already connect to Russia server. Only for all this we need to configure incoming/outgoing rules. I don't have enough knowledge for this.
How will this help if the server in Russia is in the same conditions when its traffic is filtered?
I noticed that on some Russian servers traffic is not filtered. Perhaps they are connected bypassing the TPSU or this kind of connection have "privileges". This could be a temporary solution in case of serious blocking.
I noticed that on some Russian servers traffic is not filtered. Perhaps they are connected bypassing the TPSU or this kind of connection have "privileges". This could be a temporary solution in case of serious blocking.
As a temporary solution, ok. But I don't think such a hole will be left for long.
In theory it is possible to improve the scheme with an intermediate server in Russia. As an option to set up a server in Russia as a client/server, then connect to it as a client abroad server, and we already connect to Russia server. Only for all this we need to configure incoming/outgoing rules. I don't have enough knowledge for this.
How will this help if the server in Russia is in the same conditions when its traffic is filtered?
I noticed that on some Russian servers traffic is not filtered. Perhaps they are connected bypassing the TPSU or this kind of connection have "privileges". This could be a temporary solution in case of serious blocking.
It's not privileges or bypass. They are just don't have TSPU on board.
@Applone,
They are just don't have TSPU on board.
According to my information, they have TSPU, just for there more loyal rules/limitations for connections to foreign servers. Similarly, “home” ISPs have more loyal rules/limitations for connections to domestic/RU servers (no tcp16-20 method, you can use VPN protocols such as WireGuard / OpenVPN etc). Among other things, this is indirectly confirmed by the technical support of some DC providers.
According to my information, they have TSPU, just for there more loyal rules/limitations for connections to foreign servers. Similarly, “home” ISPs have more loyal rules/limitations for connections to domestic/RU servers (no tcp16-20 method, you can use VPN protocols such as WireGuard / OpenVPN etc). Among other things, this is indirectly confirmed by the technical support of some DC providers.
But they have almost completely free Internet. They don't have Youtube, Cloudflare, etc. banned, like we have on Mobile/Home ISPs.
Maybe they have a TSPU. But it don't do much.