<story><title>Belarus finally bans Tor</title><url>https://ooni.torproject.org/post/belarus-fries-onion/</url></story><parent_chain><item><author>netule</author><text>Is it possible for anyone to share the full text of the post for those of use behind a great firewall?&lt;p&gt;Edit: thanks!</text></item></parent_chain><comment><author>bob1122</author><text>Country: Belarus&lt;p&gt;Probed ISPs: Beltelecom (AS 6697)&lt;p&gt;Censorship method: TCP injections&lt;p&gt;We have recently heard of network anomalies in Belarus. Tor has been finally blocked in December 2016, although it had been explicitly declared that Tor should be blocked since February 2015.&lt;p&gt;Directly connected users from Belarus&lt;p&gt;An anonymous cypherpunk has helped to gather some evidence regarding Tor being blocked in Belarus. It’s neither a complete study nor an in-depth research and it’s unclear if any other further evidence will be gathered, so we decided to share current knowledge as-is:&lt;p&gt;Tor directory authorities are not blocked
Public onion routers have their ORPort blocked by TCP RST injection
The onion routers’ DirPort is not blocked
Plain-old non-obfuscated Tor Bridges from BridgeDB circumvent the interference
Beltelecom (or its upstream) has strange configuration of the networking gear injecting reset packets
The strangeness in equipment is the following. The first injected RST packet does not have have proper SEQ&amp;#x2F;ACK numbers. These packet fields are just filled with zeroes. So this packet is dropped by the client’s TCP&amp;#x2F;IP stack per RFC5961 and does not actually terminate the client’s connection:&lt;p&gt;$ tshark -Tfields -eframe.time_relative -eip.src -etcp.srcport -eip.dst -etcp.dstport \
    -eip.ttl -etcp.flags.str -etcp.seq -etcp.ack -r urandom.pcap | sed | awk | perl
0.000000   192.168.1.2 42555 87.118.94.227   443  64 &lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;S* 899897236  0
0.029459 87.118.94.227   443   192.168.1.2 42555 125 &lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;R&lt;/i&gt;* 0          0 (sic!)
0.096914 87.118.94.227   443   192.168.1.2 42555  52 &lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;A&lt;/i&gt;&lt;i&gt;S&lt;/i&gt; 1984028404 899897237
0.096958   192.168.1.2 42555 87.118.94.227   443  64 &lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;A&lt;/i&gt;&lt;i&gt;&lt;/i&gt;* 899897237  1984028405
0.136874 87.118.94.227   443   192.168.1.2 42555 125 &lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;&lt;/i&gt;&lt;i&gt;R&lt;/i&gt;* 1984028405 0&lt;p&gt;That’s all for today. Remember, fried potato is better with onion!</text></comment>
<story><title>Belarus finally bans Tor</title><url>https://ooni.torproject.org/post/belarus-fries-onion/</url></story><parent_chain><item><author>netule</author><text>Is it possible for anyone to share the full text of the post for those of use behind a great firewall?&lt;p&gt;Edit: thanks!</text></item></parent_chain><comment><author>willvarfar</author><text>urandom.pcap: Belarus (finally) bans Tor
Leonid Evdokimov 2016-12-08 00:00:00 +0000 UTC
Country: Belarus&lt;p&gt;Probed ISPs: Beltelecom (AS 6697)&lt;p&gt;Censorship method: TCP injections&lt;p&gt;We have recently heard of network anomalies in Belarus. Tor has been finally blocked in December 2016, although it had been explicitly declared that Tor should be blocked since February 2015.&lt;p&gt;Directly connected users from Belarus&lt;p&gt;An anonymous cypherpunk has helped to gather some evidence regarding Tor being blocked in Belarus. It’s neither a complete study nor an in-depth research and it’s unclear if any other further evidence will be gathered, so we decided to share current knowledge as-is:&lt;p&gt;Tor directory authorities are not blocked&lt;p&gt;Public onion routers have their ORPort blocked by TCP RST injection&lt;p&gt;The onion routers’ DirPort is not blocked&lt;p&gt;Plain-old non-obfuscated Tor Bridges from BridgeDB circumvent the interference&lt;p&gt;Beltelecom (or its upstream) has strange configuration of the networking gear injecting reset packets&lt;p&gt;The strangeness in equipment is the following. The first injected RST packet does not have have proper SEQ&amp;#x2F;ACK numbers. These packet fields are just filled with zeroes. So this packet is dropped by the client’s TCP&amp;#x2F;IP stack per RFC5961 and does not actually terminate the client’s connection:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    $ tshark -Tfields -eframe.time_relative -eip.src -etcp.srcport -eip.dst -etcp.dstport \
        -eip.ttl -etcp.flags.str -etcp.seq -etcp.ack -r urandom.pcap | sed | awk | perl

    0.000000   192.168.1.2 42555 87.118.94.227   443  64 **********S* 899897236  0
    0.029459 87.118.94.227   443   192.168.1.2 42555 125 *********R** 0          0 (sic!)
    0.096914 87.118.94.227   443   192.168.1.2 42555  52 *******A**S* 1984028404 899897237
    0.096958   192.168.1.2 42555 87.118.94.227   443  64 *******A**** 899897237  1984028405
    0.136874 87.118.94.227   443   192.168.1.2 42555 125 *********R** 1984028405 0
&lt;/code&gt;&lt;/pre&gt;
That’s all for today. Remember, fried potato is better with onion!</text></comment>