— What are the Russian authorities doing now: are they blocking hosts or services individually, or attempting something more ambitious?

Currently, IP addresses and the domains of some VPN services are blocked, while more sophisticated attempts at TSPU blocking are being tested in some regions. Meanwhile, IP addresses and domains are blocked on all TSPUs.

Auxiliary domains are being blocked, as is the case with a ProtonVPN domain used to allocate server IP addresses to clients. This is what we are seeing now. There is no evidence that private servers are being blocked, only public servers, while protocol blocking remains in the testing stage. Blocking private servers can be achieved through protocol blocking, but right now the technology is only being tested on individual TSPUs, and we do not know the results of these tests yet. That is, it is quite possible that we will see protocol blocking soon, but it is also quite possible that we will never see it happen or will not see it for several months.

It all depends on the results: the testing might bring down interdependent infrastructure like state communication networks or banking channels forcing them to explore different options of VPN blocking. If they manage to block only certain protocols without affecting any important infrastructure, we could see these blocks coming soon enough.

— How exactly are VPN services blocked? Do TSPUs in each region receive a list of hosts to be blocked?

Precisely. TSPUs are controlled by Roskomnadzor from a single control centre, and they can block IP addresses and nodes of known VPN providers at all TSPUs in Russia.

— Can the developers bypass these restrictions, and will they?

Blocking the server’s IP address means that you just need to switch to the ones not being blocked. Usually, you can detect Roskomnadzor activity and provide them with fake addresses: once the IP addresses are distibuted selectively, you check which ones are blocked, and detect the censorship infrastructure ‘snitching’ on IP addresses to get them blocked.

Some VPN protocols are hard to block thanks to obfuscation and traffic masking techniques. Will the popular services bypass Russian censorship? The services we talk to, like Proton, do want to circumvent the blocking. After all, it's their business, and Russia is a fairly large market with tens of millions of users and probably several hundred million dollars a year in revenue. I think that it is quite reasonable for large services to attempt it. Time will pass – days, maybe a week – and services will slowly get back to normal. Not all, but most. Let's see if that will be the case.

In China, that's how it works. China is a big and important market. And when the Chinese apply new filters to restrict VPNs, most services usually go down, three to four services remain operational. But within a week or a month, the VPN market adapts, and number of options increases. That is, services learn from how exactly they are being blocked, and offer protocols and solutions to skirt these attempts. Therefore, I think that soon this whole thing will work itself out.

— Why are they not using protocol blocking via DPI? Only individual hosts are blocked?

Probably because they don’t know how to do it yet. Because it is quite difficult to cut through the traffic without breaking things for corporate VPNs, for example, operating ATMs or payment terminals in shops. These devices are also connected using VPN protocols. Plus they need to learn how to block certain protocols while not blocking other protocols, or make white lists of IP addresses and protocols that are not blocked. This is not a very easy job: it is feasible in general, because we see that in China or in Turkmenistan (mostly, China) attempts at protocol blocking are taking place. Apparently, Russian censors are not yet ready to do this. But they are learning, as you can see from the tests.

— Is it possible to bypass protocol blocking?

Yes, it is. There are certain protocols developed by enthusiasts, mostly Chinese, especially for networks operating under repressive regimes. These protocols make user traffic appear like the traffice from video conferencing software, for example. They pretend to forward WebRTC traffic, which is used for services like Zoom. Without knowing the IP addresses of the servers, it is impossible to block it, and there is a risk that all video conferences or video would be blocked.

Alternatively, VPN traffic could be disguised as valid https traffic, like web surfing, but with a domain substitution inside, so that the packets appear to be going to Google servers while in fact they don't. It's not that it's some tricky, elusive protocol, it's just written in such a way that it looks like a protocol for something else.

Translation: Ivan Ignatiev