News: The backbone provider RETN , despite being the backbone provider, filters the traffic by DPI. Since he is a backbone operator, and, in particular, is engaged in the delivery of foreign traffic, then at the output we have censorship for many providers, including those who wanted to chit on all sorts of "forbidden lists", but have RETN in uplinks.



DPI is the cumulative name of the technology in which the equipment “climbs” inside the traffic, that is, it reacts not only to the headers of packets of different levels, but also to the contents.



To avoid interference, the test was conducted from several cities and from several providers, which made it possible to exclude the local provider filtering factor (the second, indirect test was based on the use of TTL scanning, which always pointed to the RETN area).

')

Let's see how RETN implements DPI, jealously enforcing the laws on the protection of drugs from suicidal pornographic children who violate copyrights.



We take the widely known Stervozinki magazine as a basis (it is widely known only for being blocked, blocked for some sort of nonsense, and it has been blocked for a long time, and is not going to crawl out of the ban).



The address of this post is listed as banned by citizens of the Russian Federation. In this regard, I carried out irreversible manipulations with the domain name of the journal in such a way that there was not a single reliable and unambiguous algorithm for the conversion of the resulting hash function.



Let's look at the domestic symptoms of the problem:



wget -d --tries 1 stervozzinka.dreamwidth.og/15580.html



Next to the console, run tcpdump host stervozzinka.dreamwidth.og

 17: 17: 14.376828 IP local.49510> dreamwidth.og.http: Flags [P.], seq 1: 136, ack 1, win 115, options [nop, nop, TS val 11199749 ecr 1627034663], length 135
 17: 17: 17.924801 IP local.49510> dreamwidth.og.http: Flags [P.], seq 1: 136, ack 1, win 115, options [nop, nop, TS val 11200636 ecr 1627034663], length 135
 17: 17: 18.068805 IP local.49509> dreamwidth.og.http: Flags [P.], seq 1: 136, ack 2, win 115, options [nop, nop, TS val 11200672 ecr 1627029045], length 135

The same seq is a sign of rewinding a segment. But we cannot understand where they are blocking (upon receiving a response or sending a request). But we definitely see that they are blocking, because TCP-segments just do not resend.



Switch from mastering wget to something simpler to precisely control what is being sent:



echo -e "GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80

It will not advance us in any way, however it will give some freedom to experiment with headings. The specified request is also blocked.



But for variations (which is a violation of the RFC, but varnish from the dreamwidth is processed normally) we can see some features:

• GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n" (two spaces after GET) - lets
• GET /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n (two spaces before HTTP / 1.1 - do not allow
• get /15580.html HTTP/1.1\nHost: stervozzinka.dreamwidth.og\n (get small letters) - lets
• GET /15580.html HTTP/1.1\nIgnore:me\nHost: stervozzinka.dreamwidth.og\n (an extra header between GET and HOST) - does not allow

The preliminary conclusion is boring and primitive exact matching. If so, how does it understand that the contents of the package header, and what is not?



So that…



echo -e "GET /15580.html\n\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80 - do not allow.



For those who do not understand - I put two line breaks after GET, that is, Host already refers to the body, not to the header. I also removed HTTP / 1.1, that is, this is plain HTTP 1.0, which does not have a Host header, that is, we requested /15580.html from the server without a reference to the hostname.



Note that the query without the hostname works: GET /15580.html \n\n



In other words, we see that DPI is checking for something completely unreal - the presence of a Host in BODY. As a result, requests that have no relation to the blocked site are dropped.



Let's complicate the experiment:

echo -e "POST / \ n \ nAnd do you know that they are banned by content? For example: GET /15580.html \n\nHost: stervozzinka.dreamwidth.og\n"|nc stervozzinka.dreamwidth.og 80



Oh oh oh. We were banned from sending POSTs with innocent content. This POST did not reach the server. Can not be?



Let's check, and send the post more cultural methods:



curl -d "GET /15580.html \n\nHost: stervozzinka.dreamwidth.og\n" dreamwidth.og



Our assumption is that the filter requires both lines in one package and does not check its validity:



curl --connect-timeout 10 -d "GET /15580.html\n`seq 1 10000`\nHost: stervozzinka.dreamwidth.og\n" 69.174.244.50



Passes by This means that the package should have both headers. (yes, if we write such a request to a server that has Host: in the header goes in another package, then maybe we can break through the censorship.



Another check: do people check the port number?

echo -e "GET /\nHost: stervozzinka.dreamwidth.og\n"|nc dreamwidth.og 443

(empty answer)



echo -e "GET /15580.html\nHost: stervozzinka.dreamwidth.og\n"|nc dreamwidth.og 443

(time-out)



Not. Traffic to port 443 is filtered with the same success (they let pass normal, drop “forbidden“).



Another check: do they filter by IP? We find the next (from the same segment) open IP, which responds to port 80. Let it go.

Total

Conditions for package drop:

• On any TCP port (UDP was not checked)
• With any flags
• According to the actual presence in the package (in any order) rows
  • GET /15580.html
  • Host: stervozzinka.dreamwidth.og
• Match src_IP with specified in ban list

Thus, it is more like a packet filter with signature search without regexp in passing packets, and not at all a real DPI.