What's New in the World of Block Bypassing in Mid-2024
Once again about YouTube
Let's start with what happened literally yesterday: the speed limitation to YouTube. The official position of some telecom operators sounds like “There used to be a lot of Google Global Cache servers, they are becoming outdated, so everything is starting to slow down.” On the one hand, it sounds quite plausible, but on the other hand, it is somehow quite strange that many operators on Friday suddenly took outdated GGC servers overnight, which had been working fine the day before.
Have you heard of planned obsolescence? Well, it seems like someone has planned it. On one forum known in narrow circles, people test different hypothesesand guess what? In most cases, the “slowdown” of YouTube disappears when using TSPU bypass tools like GoodbyDPI and Zapret, which fragment the SNI field from the handshake (which contains the destination server domain). That is, when Roskomnadzor's TSPU equipment cannot determine that the user is connecting to the domain *.googlevideo.comthen everything works fine, and when it can, packet losses begin, which causes a sharp decrease in access speed, despite the fact that in both cases the connection is made to the same IP addresses.
Blocking Shadowsocks, VMess, Outline
In late April – early May, Roskomnadzor started having fun with blocking fully encrypted protocols – such as VMess and Shadowsocks (and therefore Outline, which uses it). They were blocked before, when RKN, trying to block Telegram proxies during certain events, cut all “unidentified” protocols, but, of course, this approach had huge collateral damage (roughly speaking, everything that TSPU could not identify stopped working, for example, people's Radmin clients fell off). Now everything has become much more subtle.
The essence of the blocking can be illustrated by the following picture:
In the picture we can't see what's inside the boa constrictor, but by its external shape we can guess what it is.
RKN implemented blocking in a similar way. The VMess and Shadowsocks protocols lack any characteristic features, and the transmitted data is completely encrypted. But at the same time, the most common HTTPS with TLS runs inside them, so the sizes of transmitted packets and their sequences during TLS handshake directly affect the sizes of transmitted packets and their sequences for a transport protocol like Shadowsocks. For example, at least one blocking template on censoring equipment for all unidentified protocols looks like this:
The client sends three packets, each containing 411+ random bytes
The server sends an arbitrary number of any bytes more often than the client sends its packets
When these conditions are met, the connection is blocked. Or perhaps they block by packet size, perhaps not by absolute numbers, but by the ratio of the size of the sent to the received.
The table of tests on different operators can be found here: Analysis of blocking in Russia. All entries in one table. (github.com)
A fully restored graph of the logic of the locks looks something like this (high resolution version):
I'll send those interested in a post on the same forumwhere people analyzed in detail the behavior of blocking on different providers (Rostelecom, Er-Telecom, Ufanet, MTS, Megafon, Beeline), collected dumps and identified patterns. There is also a thread on the well-known Net4People board: Blocking of fully encrypted protocols (Shadowsocks, VMess) in Russia, targeting HTTPS traffic fingerprints Issue #363 net4people/bbs (github.com)
Removing VPN apps from the AppStore
In early July, Apple, at the request of Roskomnadzor, removed several VPN service apps from the AppStore that are used to bypass blocking. At least four are known – Proton VPN, Red Shield VPN, NordVPN and Le VPN. How to treat Apple after this and whether to trust them – everyone decides for themselves.
HTTUpgrade
Now about what's new in XRay and the company. The first thing is the “HTTUpgrade” transport. In fact, the same websockets, but with a slight simplification. Websockets are an extension of the HTTP protocol, when the client and the web server agree with the special “Upgrade” header “let's now send data not as a request-response, but just as we want”, and the connection switches to the “data pipe” mode. In addition, when exchanging data via websockets, each sent data packet is wrapped in the so-called “websocket frame”. This is done because the TCP protocol (over which HTTP/HTTPS work) is a streaming protocol, that is, roughly speaking, it does not separate the boundaries of the transmitted data. For example, you send a 50-byte message to the TCP stream, and after a while another 50-byte message. There is no guarantee that the data will be received at the other end in exactly the same way, in the form of two 50-byte messages. It is possible that 100 bytes will arrive in one piece, or it may arrive first 20 bytes, then 60 bytes, and then the remaining 20 bytes. That is why special frame headers are added to web sockets to control these boundaries so that software developers can not rack their brains about all this, but simply send messages and receive them on the other side exactly the same way as they were sent.
The XRay developers realized that none of this is necessary for proxying purposes. In the case of TCP proxying, all of this is done at the level of the protocols and applications whose traffic you are proxying, and in the case of UDP, at the level of the proxy protocol. So they created a transport called HTTPUpgrade, which establishes a connection in the same way as regular web sockets (with the “Upgrade” header), but sends information without additional wrapping in web socket frames. As a result, data transfer is more efficient (less overhead on headers), such traffic is harder to detect, and it still allows you to crawl through web servers and popular CDNs (which do not care at all about the presence or absence of web socket frame headers, they just transfer the data as is).
HTTPUpgrade has been available in XRay for a few months now, and support for it has already appeared in many popular clients.
Split Tunnel
It gets more interesting. What if we want to proxy traffic through CDN or corporate gateways, but they do not allow web sockets? For example, Cloudflare, Amazon Cloudfront and GCore support web sockets, but Fastly asks for extra money for them, and MS Azure and CDN77 do not know how to work with web sockets at all. And this is very disappointing, because it is precisely these “incapable” CDNs that still allow domain fronting (the article about it is here, it is prohibited in Russia, but is available via proxy/VPN). Remember XTLS-Reality, which allows you to disguise yourself as a real foreign domain with a real TLS certificate? Domain fronting allows you to do approximately the same thing, but via CDN.
The problem is that if we do not use web sockets, we are limited to regular HTTP requests only. And the interaction in this case can only be of the “request-response” type, i.e. without receiving a response, we cannot send the next request. For a long time, the only option to work in this mode and to get through such CDNs was the Meek transport from the Tor developers. It works indecently simply: we establish a connection, and in an endless loop we send GET/POST requests and wait for responses. If we have something to send to the proxy server, it will be sent in the request, if there is any data that the server wants to send us, we will receive it in the response. All this worked rather slowly, and created a significant load on both the remote server and the CDN, even at those moments when no data was transmitted.
And here the XRay developers came up with a good idea. They divided the connection to the proxy into two parts – one for sending data, the other for receiving data, and inside the connection they used a mechanism like long polling. The result was very cool – there is no need to send requests and responses back and forth every second, you can limit yourself to just a few connections, and at the same time the traffic “there” and the traffic “back” go different ways, which significantly complicates its analysis and blocking.
One BUT – it is necessary that the CDN and web server do not buffer data in requests and respect the header `X-Accel-Buffering: no`. I tested it, Gcore CDN works with such transport without problems, CF and Amazon have not yet checked, who tried – tell me how it is there. Of the web servers, Nginx and Apache definitely work, but through Caddy there is a blockage, perhaps something needs to be tweaked in the config.
Like HTTPUpgrade, SplitTunnel is just a transport for other protocols. And as a proxy protocol inside SplitTunnel you can use the well-known VLESS or Trojan.
SplitTunnel support appeared in XRay version 1.16, and literally yesterday version 1.17 was released with fixes and improvements. The new transport has not appeared in the clients yet, as usual you need to wait a month or two.
WebTunnel
Tor is not standing still either. If you follow what is happening, you probably know that most public Tor nodes in Russia and similar countries are blocked, since their addresses are available in open lists. To solve this problem, a long time ago a mechanism of “bridges” was invented, the addresses of which are given out to users who request them. For a long time, the standard transport for such bridges was obfs4, similar in principle to the above-mentioned Shadowsocks and VMess with all the corresponding shortcomings (see. How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic | USENIX). Tor developers, in accordance with the trends of the times, are looking for new transport options, and recently in experimental mode they sawed off a new transport for bridges called WebTunnel. Yes, these are the same web sockets 🙂
For now, you can only request a WebTunnel bridge address through the website: https://bridges.torproject.org/options Bridges of this type are already supported in all official clients. In the mobile Tor Browser there is no separate item when choosing the bridge type, but when inserting a connection string with a WebTunnel bridge, it correctly picks it up and connects as needed.
The connection string looks something like this:
webtunnel [2001:db8:f9e3:eb5a:eeee:3d:1da5:166e]:443 13EA8F4B49276D43ABCDED91C5B3976F599C url=https://someserver.com/ThJwaIl5uOzrpQnZPJBEKsA2 ver=0.0.1
Don't be alarmed that you see something similar to an IPv6 address in the line, but you don't have IPv6. For WebTunnel, the entry point is a domain name. And the fact that you see 2001:db8::/32 is, let's say, a feature of the Tor bridge architecture, which must always have an IP address, and since there is clearly no point in providing an IP address for webtunnel bridges, they came up with such a hack and generate virtual IP addresses from a “non-existent” range (this range is reserved in the standard for documentation and examples).
Call for bridges!
And here it is important to say one thing. There are still few WebTunnel bridges, but you can help people to make them many.
If you have your own VPS with some website and domain – install it on the Tor server in bridge mode with WebTunnel transport!
Manual installation not simple, but here it is using Docker this can be done very easily. The instructions can be found here, you only need to edit the .env file, specifying your domain there and coming up with some “secret URL”, launch the Docker container, and write it into the config of your web server (definitely works with Nginx and Caddy) so that requests to the “secret URL” are transmitted to Tor.
It doesn't consume many resources, a VPS with 512 megabytes of RAM works quite well, and a machine with a gigabyte of memory can even host two Tor bridges at once (you can host up to two bridges on one IP address). It doesn't generate much traffic, depending on how many users your bridge is shared with, usually no more than a dozen megabits per second.
What to do if you want to help, you don't have a website or domain, but you have a server? Get the Snowflake bridge! Snowflake is another pluggable transport option for Tor, using WebRTC (like video calls in messengers). Its installation is very simple, literally in two steps: you can use DockerCan i download and build binary yourself. Every hour the proxy writes statistics to the logs, how many users were connected to you during this time and how much data was transferred. Snowflake-proxy is written in Go, does not require any dependencies. It is important that UDP ports 30000-60000 are open on the firewall.
What to do if you want to help, but you don’t have a website, a domain, or a server, you’re far from all of this, but you live in a country where Tor is not banned, and you want to do a good deed? Install Snowflake Browser Extension. It works in Firefox, Chrome, Edge. When you activate it in the browser, your computer will start working as a Snowflake proxy. Tor developers understand perfectly well that it is important not to create inconvenience to users, so the number of simultaneously connected clients will be limited to two. It may seem to you that this is very little, but in fact, such “home” snowflake bridges have the greatest value – because in many countries with strong Internet censorship, connections to the IP range of large hosting providers are filtered, and you with your Residential IP can be that very magic wand.
And yes, here we need to talk about one myth associated with Tor. When people hear “set up a Tor bridge”, they immediately start thinking that in this case someone will be able to access the Internet from their address and do some bad things on their behalf. No, no and no again. You should not confuse bridges and exit nodes, with which this can really happen. If you set up a bridge, your address will be used only to connect clients from countries with internet censorship with other Tor nodes. Tor chains usually consist of three hosts, and when you have a bridge running, you can only be the first node in this chain, but certainly not the last. This carries absolutely no risk, but you are doing a good deed and helping people around the world fight government internet censorship.
AmnesiaVPN
AmneziaVPN is also not standing still. They have a lot of new things in the last months. They added killswitch, added split tunneling for Windows and Android, they have been experimenting with XRay for a long time and recently added XRay support for iOS and Android.
Changelog can be found here: Releases · amnezia-vpn/amnezia-client (github.com)well, and check out their blog Amnezia VPN
Meanwhile in Telegram…
And finally, a lyrical digression. Some time ago, I came across Telegram groups and Telegram bots selling “subscriptions” (or “keys”, it's the same thing) for proxy servers with VLESS, XTLS-Reality, etc. For the sake of interest, I even spent some money and time to study what it is and how it works… And mama mia!
The business idea, which has obviously occurred to more than one person (I suspect that most often these are high school students or students), is very simple:
We buy a couple of the cheapest VPS for 200-300 rubles per month
We install XRay there (often even immediately with the X-UI or Marzban panel)
We attach a Telegram bot to this to accept payments and sell “subscriptions”
We sell these “subscriptions” for 200-300-500 rubles to dozens or even hundreds of users
????
PROFIT!
You've probably already guessed about the quality of such “services”. From what I found in almost all of them:
1. Speed and stability are so-so, often noticeably lagging;
2. Output IP addresses are often poisoned (Google requires a captcha for every sneeze, Instagram simply stops letting you in periodically);
3. No guarantees, the service can break down and stop working at any moment. Paid money for a month in advance or even more? To whom I owe – I forgive everyone!
4. Often everything is set up rather crookedly and with childish mistakes. MiraclePtr, the author of the legendary articles about the correct XRay setup, would probably still commit seppuku if he knew how people follow his instructions and heed his warnings;
5. The most interesting thing is that services for 400-500 rubles work no better than services for 100-200. Moreover, the louder the owners of such services shout in chats that “everything is fine with them, that's why it costs more”, the greater the risk of discovering that everything is done even more crookedly and works accordingly.
However, I met a couple of comrades who have done everything more or less sensibly and it works well, but considering, so to speak, their views and rhetoric in chats, I will not be surprised if sooner or later it turns out that they are leaking all the access logs of all their users somewhere to the authorities, so to speak, showing civic vigilance.
What's the moral of the story? Don't use shady services from anonymous people if you don't want to lose money and get crap. The best proxy server is the one you set up yourself, fortunately, it can be done very easily (see the instructions from MiraclePtr, it is not accessible from Russia, but you can open it via proxy/vpn). If it's still too difficult for you, then use AmnesiaVPNwhich I already mentioned above.
If this is too difficult, there is AmneziaFree and VPN Generator (see also their tg-channel). Both projects are free (non-commercial, so no advertising) and resistant to blocking.
And if you really want to give money to someone, then it is better to prefer well-known projects, behind which stand well-known network activists. Fortunately, many of them are also seriously concerned with bypassing blockages and offer, among other things, protocols of the VLESS and XTLS families.
