DPI-resistant tunnels and VPNs

We live in an interesting time. I would even say amazing. On one side, we see some people who really want to know what other people are talking about among themselves, and they really want to tell them what to read and what not. On the other hand, citizens who want to defend their rights of secrecy of personal correspondence and the free receipt of information, and do not want the facts of this correspondence and the receipt of this very information to be used against them. The bonus suffers a huge number of third-party sites, services and businesses that are affected by "carpet locks".

But no, this article is not about society, but about technology.



Technical literacy of people, thanks to everything that is happening, is also growing. If earlier the words “VPN” and “proxy” were familiar only to IT-specialists, now even housewives know them, and moreover - they use what these words mean.

In general, the news has recently come very interesting. For example, the provision of VPN and similar services for encrypting traffic and bypassing blocking is now punishable , and in China they are imprisoned for it . Not long ago, the RKN began using packet analysis to block the MTProxy protocol. You can also refer to the experience of fellow countries that are most successful in such matters: China, Iran, Kazakhstan, Venezuela. In Venezuela, for example, it is quite specifically blocking direct connections to Tor and obfuscated traffic to bridges. Based on all this, we can assume that the future is also very interesting for us, especially if the "responsible persons" stop making stupid fakapy time after time, but they act smarter and more sophisticated.

On Habré, many times in the comments voiced predictions of how further the struggle with encryption technologies for ordinary citizens can occur. Analyzing the voiced thoughts and looking at the evidence from other countries, I tried to suggest in which direction the measures to limit communication could move further. DistortNeo and shifttstas planted some more interesting ideas, and in the end I promised el777 to add this article.

With filters on ACL everything is generally clear. They act now, and it turns out with varying success and it is impossible to fight (although there are quite pessimistic forecasts ). With DPI everything is more interesting.

Methods of "determining" the type of traffic in DPI can be divided into two groups:

• Signature analysis. Namely, sorting the package “by bone”, comparing the headers and structure with the samples, and thus determining its purpose. Many tunnels are detected this way, for example, OpenVPN, L2TP / IPSec, SOCKS, etc.
• Preliminary analysis of traffic exchange patterns, for example, the ratio of incoming / outgoing flow, the frequency of requests and responses, and other criteria will allow you to separate the "real traffic" of a protocol and the tunnel, only disguised as it.

You can break traffic into several groups and assume what they will do with each of them.

1. Explicit VPNs, tunnels, and proxies (OpenVPN, L2TP / IPSec, SOCKS, and others.) Ordinary VPNs and tunnels may well automatically be blocked, such as in China and Venezuela. If some organizations or companies need it for work, let them be registered and certified, which is exactly what the Russian law mentioned above says. With a proxy, it is still easier - that HTTP, that SOCKS transmit addresses and content in clear text, which does not create any problems for selectively “cutting” requests and listening to the transmitted information.
2. Dual-use technologies, such as SSH . After a short time after the session is established, the speed is cut to a snail, so that in the console it is still possible to work somehow, but to surf and swing something is no longer there. The fact that this creates problems during normal work does not bother anyone (which has been shown to us by the RK more than once in recent times).
3. Highly specific protocols such as messengers, gaming clients, etc.
4. Compounds whose type cannot be determined .

For points 3 and 4, whitelists are quite possible (in which, for example, the subnets of the official game servers or the "correct" messengers are entered, and all that the owners of the servers wish to declare and arrange as necessary so that they are not touched, by analogy with those that already have at RKN for domains and IP addresses). And those who are not in these lists are waiting for the same fate as item 1 or item 2, although it’s quite possible that not stupid blocking or cutting speed is possible, but the previously mentioned analysis of exchange patterns in order to determine whether traffic is “clean” Or suspicious.

That is, if you wish to disguise as special protocols, or obfuscate connections, so that it is impossible to determine their type, you will also have to take care of creating a “noise” that prevents the actual identification of exchange patterns. So far, such developments have not come across my eyes.

You can not even remember about different ICMP and DNS tunnels - a large amount of traffic “where not necessary” for them also automatically causes suspicions.

5. TLS and SSL, HTTPS . Cutting clean is impossible, because it automatically means blocking the entire Internet. Pattern analysis does not make sense, since surfing the web is the main purpose of using HTTPS. Of all of the above, SSL / TLS on port 443 looks like the most “unsuspicious” and reliable option. Therefore, let's try and disguise it.

Masquerading

For consideration, it was decided to choose solutions Streisand and SoftEther.

Streisand is a whole set of various services: OpenConnect / AnyConnect, OpenVPN, stunnel, Shadowsocks, WireGuard. All this is put in automatic or semi-automatic mode on a turnkey basis, and the user gets a configured server, as well as files and detailed documentation for setting up clients, at the output.

SoftEther is a VPN server that can enable L2TP / IPsec, OpenVPN, SSTP, and other protocols, and also has its own SSL-VPN protocol, which, according to the authors, is indistinguishable from ordinary HTTPS traffic.

So…

OpenConnect / AnyConnect. An open source implementation of the AnyConnect SSL protocol from Cisco. When establishing a connection, not only TLS (TCP) packets are visible, but also DTLS (UDP). DTLS, in principle, is also used a lot for “peaceful purposes”, but this is not at all like “ordinary HTTPS”.

Shadowsocks . Encrypted SOCKS proxy. Apparently, if desired, can be detected , but there are plugins that mask it under "pure HTTPS" .

Wireguard Judging by the description, it has a well-twisted encryption and session setup mechanism, but the entire exchange takes place via UDP. Wireshark defines the type of packets as something completely unintelligible, and what kind of opinion about everything that happens will be formed at third-party DPI is a very, very big question.

obfs3, obfs4 . Obfuci packages so that from the outside they look completely random set of values. That is, fall under paragraph 4 of the list above.

SoftEther . It looks like HTTPS, but with one catch. In addition to TLS over TCP itself, it actively sends UDP packets in bursts. As it was possible to find out in the documentation, UDP can be used to speed up data transmission in the case when it is not slaughtered on the firewall. This functionality is disabled in the configuration, and after it is turned off, everything becomes as it should.

Sstp . VPN puncture from Microsoft. Natively supported in Windows, auxiliary software in GNU / Linux. From the side it looks like HTTPS, and Wireshark fully confirms this.

But that is not all

Suppose you install a VPN server or end of a tunnel on a host and configure it to listen to port 443. It would seem that everything is fine, but there is one BUT: if we mask under HTTPS, check that it actually hangs on port 443, you can simply try to dig into this port with a simple browser or CURL, or in any other way. In some articles, this method is called "forward connection", and, as mentioned, is already fully used in China.

Therefore, we need to have the most ordinary and decent web server on port 443. And here comes an interesting problem.

None of the above services in the main documentation found a description of the working mechanism of port sharing. The SSLH option is not suitable, if only because sslh is not able to divide traffic between HTTPS and the above services. At least, because if the type of traffic without full decryption could distinguish sslh, then DPI will be able to.

Most manus, like this , suggest using Server Name Indication (SNI) - a TLS extension that allows you to specify the host name, and then use HAProxy, sniproxy, and other bodies to scatter connections across services. The problem is that the host name specified when using SNI is transmitted to plain text, that is, unencrypted, and, therefore, can also be overlooked and used later.

Therefore, we will improvise, and here two options came to my mind.

Port knocking

Port knocking is just designed to activate the "hidden services" on the server. For example, in this way, the port on which the SSH daemon hangs is often closed out to avoid brute force and the use of 0-day vulnerabilities. In the classic version (see, for example, the implementation of the knockd daemon), knocking usually means trying to establish a connection or send packets to certain ports of a host in a certain sequence, as a result of which the daemon “recognizes” itself and activates the firewall rule that opens only from your IP.

In our case, this option is not quite acceptable. Firstly, the “non-standard” ports themselves may be blocked somewhere along the way, and secondly, the procedure itself may look suspicious when analyzed from the outside. Since we are disguised as HTTPS, then we need to “knock” on HTTPS.

Surprisingly, HTTP / HTTPS nokers with the required functionality were not found, and therefore a noker with the romantic name Labean was born (hussars, be silent!).

It is given: our server, where Nginx runs on port 443 with correctly configured certificates and provides some kind of innocuous content, for example, GIFs with cats, ISO images of GNU / Linux distributions, or a mirror of Wikipedia and the Moshkov library.

At the same time, the following lines are hidden in the Nginx config file

 location ~ ^/somesecret/(.*) {
    auth_basic      "Administrator Login";
    auth_basic_user_file  /var/www/.htpasswd;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_pass http://127.0.0.1:8080/$1;
  }

, CURL'
https://ourserver.org/somesecret/vpn/on
, , , IP-, -
iptables -t nat -A PREROUTING -p tcp -s {clientIP} --dport 443 -j REDIRECT --to-port 4443
.

N (, ) , , , IP .

, , URL , /off .

, IPv6 (v6- X-Real-IP ).

Go, , , . , nginx init- Gihub:
https://github.com/uprt/labean

Websockets

: HTTPS — . Web- TCP , Websocket (RFC 6455). HTTP-, , TCP-. , , HTTPS .

WS- ( Haskell), wstunnel, nodejs , .

. wss://-,

wstunnel -t 33 wss://server:443

, «» ws- «» . wstunnel, , URI - :

wstunnel -t 33 wss://ourserver.org:443/hiddenws/

:

, 443 Nginx c - .

proxy- Websockets-:

location /hiddenws {
    proxy_pass http://127.0.0.1:8081;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
  }

websockets-. SOCKS- (, Dante), OpenVPN, , , .



— SOCKS- VPN- wstunnel, «» .

- , — . , , — , , . , HTTPS — , , - « »/ /etc., , « », .

, , , , — , , , .
.