Just an explanation of what's probably happening in Russia now https://habr.com/ru/articles/1044396/. But I believe that there are more fingerprints banned and probably there are some other unknown vulnerabilities. So everyone is switching to Naive proxy now, and I will probably also have to do this in the future. All I want to do is to help X-ray as much as I can.
So the actual text:
The algorithm doesn't rely directly on the specific IP addresses of intermediate nodes in the network (e.g., your servers). This is actually a good thing, as it means these nodes aren't blacklisted. This is especially true given that some applications are snooping. However, the bad news is that entire subnets and even ASs are affected, including those of popular Russian data centers (e.g., Selectel, Yandex.Cloud, Cloud.ru, etc.). This is significantly different from methods that only affected foreign providers—TCP 16-20 (aka I4-25), etc.; we'll refer to such subnets as "suspicious" from now on.
So, the point is that the censor evaluates the ClientHello during the TLS handshake for each TLS connection. Among other things, it takes into account the following attributes:
The server's IP address (more precisely, its subnet, AS, or even broader "network" attribute);
SNI (Server Name Indication);
The "browser" fingerprint (or rather, the fingerprint of anyone trying to impersonate it, which is what Reality does via uTLS).
The algorithm is based on these attributes (if the answer to any question below is "no," we allow the traffic without restrictions; if "yes," we analyze it further down the chain):
- Is the IP address part of a "suspicious subnet"?
- Is the "browser" fingerprint suspicious? These fingerprints, on average, include those from Chrome, Safari, and iOS (though Firefox, Android, OkHttp, Edge, 360 Browser, and QQ Browser are currently supported by most operators);
- Have there been more than three concurrent attempts to establish a TLS connection to the server (i.e., with a delay of less than ~20-50 ms between them) in the last 60 seconds? And this is within the same SNI, meaning changing it resets the number and changes the context. It's also worth noting that dozens of simultaneous connections are typical for different clients to bypass restrictions, especially if muxes and other similar devices aren't used.
If the answer to the last question is yes, then all current and future connection attempts are frozen for 120 seconds.
An interesting detail:
If you manage to freeze connections for 120 seconds (which, of course, isn't very difficult), and then try to change the browser's fingerprint (including to an unsuspicious one), you'll also be blocked for 600 seconds. During this time, any TLS connections are frozen (TCP connections are allowed), regardless of the fingerprint and SNI.
Just an explanation of what's probably happening in Russia now https://habr.com/ru/articles/1044396/. But I believe that there are more fingerprints banned and probably there are some other unknown vulnerabilities. So everyone is switching to Naive proxy now, and I will probably also have to do this in the future. All I want to do is to help X-ray as much as I can.
So the actual text:
The algorithm doesn't rely directly on the specific IP addresses of intermediate nodes in the network (e.g., your servers). This is actually a good thing, as it means these nodes aren't blacklisted. This is especially true given that some applications are snooping. However, the bad news is that entire subnets and even ASs are affected, including those of popular Russian data centers (e.g., Selectel, Yandex.Cloud, Cloud.ru, etc.). This is significantly different from methods that only affected foreign providers—TCP 16-20 (aka I4-25), etc.; we'll refer to such subnets as "suspicious" from now on.
So, the point is that the censor evaluates the ClientHello during the TLS handshake for each TLS connection. Among other things, it takes into account the following attributes:
The server's IP address (more precisely, its subnet, AS, or even broader "network" attribute);
SNI (Server Name Indication);
The "browser" fingerprint (or rather, the fingerprint of anyone trying to impersonate it, which is what Reality does via uTLS).
The algorithm is based on these attributes (if the answer to any question below is "no," we allow the traffic without restrictions; if "yes," we analyze it further down the chain):
If the answer to the last question is yes, then all current and future connection attempts are frozen for 120 seconds.
An interesting detail:
If you manage to freeze connections for 120 seconds (which, of course, isn't very difficult), and then try to change the browser's fingerprint (including to an unsuspicious one), you'll also be blocked for 600 seconds. During this time, any TLS connections are frozen (TCP connections are allowed), regardless of the fingerprint and SNI.