Somewhere around a month ago obfs4 and WebTunnel bridges hosted on some ASNs stopped working for users in Russia.
The problem is not that “we can’t even fool” the censorship DPI machines about the SNI of the WebTunnel bridge we’re connecting to, but it’s as if all connections are affected, so it’s not a Tor-targeted or Tor-bridge manual block. Since WireShark shows me that some packets come through, then others get blocked after some time to the bridge, because some packets get through, it means that the block is not blocking the IP of the bridge and this generally means that you can bypass it. A big provider that’s affected is Hetzner, but not only it’s affected.
I tried using this zapret fork with a set of arguments you can choose from with the WebTunnel bridges affected. (mind you, zapret in general requires sudo or root permission) That fork is built for Windows, but you can technically just copy the arguments and use them in other OS’es by downloading the original zapret. There’s also a fork of the fork of zapret which is optimized for linux, but be careful using it, since it’s not that popular or widespread. You should add the bridge domain to the hostlist for it to get routed.
And that fixed the block. So bridge operators can either switch ASNs for easier access for users, or the Tor Browser pluggable transports can have something similar to this zapret fix.
Either way users can bypass that block by using zapret with “an advanced argument”, such as the ones in the fork I mentioned.
@reseacher @Oneshotter @gus
2 Likes
I don’t know which ports Tor uses. But apparently these strategies work. Similar to the ones I described above.
Also, according to reports, using this method you can connect without bridges on some providers
–filter-tcp=443 --hostlist=“%LISTS%list-google.txt” --ip-id=zero --dpi-desync=multisplit --dpi-desync-split-seqovl=681 --dpi-desync-split-pos=1 --dpi-desync-split-seqovl-pattern=“%BIN%tls_clienthello_www_google_com.bin” --new ^
–filter-tcp=80,443 --hostlist=“%LISTS%list-general.txt” --hostlist-exclude=“%LISTS%list-exclude.txt” --ipset-exclude=“%LISTS%ipset-exclude.txt” --dpi-desync=multisplit --dpi-desync-split-seqovl=568 --dpi-desync-split-pos=1 --dpi-desync-split-seqovl-pattern=“%BIN%tls_clienthello_4pda_to.bin”
–filter-tcp=443 --hostlist=“%LISTS%list-google.txt” --ip-id=zero --dpi-desync=fake,fakedsplit --dpi-desync-repeats=6 --dpi-desync-fooling=ts --dpi-desync-fakedsplit-pattern=0x00 --dpi-desync-fake-tls=“%BIN%tls_clienthello_www_google_com.bin” --new ^
–filter-tcp=80,443 --hostlist=“%LISTS%list-general.txt” --hostlist-exclude=“%LISTS%list-exclude.txt” --ipset-exclude=“%LISTS%ipset-exclude.txt” --dpi-desync=fake,fakedsplit --dpi-desync-repeats=6 --dpi-desync-fooling=ts --dpi-desync-fakedsplit-pattern=0x00 --dpi-desync-fake-tls=“%BIN%tls_clienthello_www_google_com.bin”
2 Likes
That’s really bad if Tor uses random ports (check wireshark to make sure), but in this case, this will either break internet or cause network spam. If port is unknown and ip is unknown, then in zapret2 anyone could write function and custom payload detection in lua which would allow to selectively only filter guard node traffic
Alternatively, since guard nodes are public, one could offload the ip database and add them into zapret’s custom scripts, like censors get their lists, you get yours for opposite reason
1 Like
Thanks for sharing! I would not recommend publicly sharing the bridge ip-port information as it would allow it be blocked by their address. It is better to just update this information locally. Publishing a list of relay address will not have this problem since they are already public anyway.
1 Like
Would it be possible for a tool to bypass this kind of block without using root permissions? It seems like at some point (like sending fake additional packets, other stuff) these programs start requiring root access. I don’t know if that’s dangerous if it’s from a tool you trust, though, but the Tor Browser censorship circumvention tools avoid using root access, so should the users always manually configure this, should the Tor Browser have some sort of similar fix (even with a prompt for root access), or should traffic modification be implemented in lyrebird/WebTunnel/obfs4 itself so it was possible to bypass the blocks without any root-access prompt? (I know, the last one sounds so unreasonable…
+ Do you know how to manually set nfqws configs in zapret? (such as the ones provided in the Flowseal fork)
We have the ability to restore many bridges in Russia using this method.
I’m also curious whether this method will work in China? Or they have other traffic filtering methods and zapret doesn’t work?