Open ignoramous opened 3 years ago
Android restricts un-privileged applications from opening raw IP sockets, but may be VPN apps can (or may be, we don't even need to)? If not, then these strategies couldn't be applied. https://stackoverflow.com/questions/2608478/raw-sockets-on-android
Probably, even if impl is possible, the 3rd strategy breaks unsuspecting servers too?
Based on ISP the behavior is different.
For example paid vpn services (foreign ones that people normally can't buy them works even if they use default openvpn port (udp protocol in port 1194)
But famous ones that offer free service get blocked in many ISPs.
For example Psiphon, Lantern and Ultrasurf don't work in many ISPs but works in some isps (with low speed although)
Also port is important in some tools, for example many things that mask their traffic as https works.
Shadowsocks on port 443 mostly works.
But these are current normal mode of their blocking, if they make it harder (in some important day/months) then for example the only thing that worked was a connection that masked its fingerprint for https. (With low speed of course)
Some ISPs completely blocks dns servers, some ISPs block that exact dns server if you use DoT (because of its specific port (853))
And sometimes some dns servers like google works but only in port 53 (plain dns)
Also in many ISPs most famous (or rather famous dns servers are blocked completely)(for example Adguard dns is completely blocked in all protocols (plain port 53, DoH, DoT)
By the way seems that after telegram blcoked here and vpn usage become high and government made aware of them, then they are trying to authenticate to provide internet (when it will be ready we don't know and what it will become in its final form still is unknown but one thing that is know that they ordered ISPs to reduce foreign traffic speed to about 20 percent of what it is now.)
Also seems that sometimes their softwares are sensitive to https fingerprint of clients also.for example masking https traffic fingerprint of an application as chrome have more success than masking it as firefox https traffic fingerprint.
Also in some ISPs (very big ones like mobile carriers even normal browsing of foreign websites have problems sometimes)
It is not stable to explain, it is odd. Seems that they are always test different things :/
Circumvention Strategy 1
The first strategy works by simply sending two additional packets before the 3-way handshake: two empty packets with the FIN flag set.
Circumvention Strategy 2
The second strategy is stranger than the first. This strategy works by sending nine copies of the ACK packet during the 3-way handshake.
Circumvention Strategy 3
Beyond exploiting the whitelister’s shortcomings at the TCP layer, we can also use Geneva’s strategy engine to bypass the whitelister by simply injecting one of the protocol fingerprints into the start of the connection.
Ref: https://geneva.cs.umd.edu/posts/iran-whitelister/
Use: http://github.com/google/gopacket or https://github.com/google/gvisor/blob/e64458ff/pkg/tcpip/stack/conntrack_test.go#L46
More: https://github.com/net4people/bbs/issues/9