Version 6 (modified by phw, 6 years ago) (diff)

Added information about the 3 blocked public bridges and manufactorer.

Ethiopia (#6045)

Summary of the current situation

DPI boxes look for Tor TLS server hellos sent by relays or bridges to Tor clients. If such a packet is found, it is dropped. The DPI boxes seem to operate in-band and stateless.

First witnessed

The block became known at May 22, 2012. According to the metrics page, the block might have started several days earlier. A blog post was published at May 31st.

Last witnessed

The block is still ongoing.

Type of Tor censorship

  • Deep packet inspection: #6045
    • Fingerprint: Multiple strings in the Tor TLS ServerHello/Certificate/ServerKeyExchange/ServerHelloDone records are matched (#6045). If a packet matches, it is dropped.

Types of non-Tor censorship

Ways to bypass censorship

  • Bridges were patched to pick the cipher TLS_DHE_RSA_WITH_AES_128_CBC_SHA instead of TLS_DHE_RSA_WITH_AES_256_CBC_SHA. This was sufficient to evade the DPI boxes. Three patched bridges were published in a blog post. However, all three bridges became useless at the beginning of July 2012. They appear to be blocked on the IP layer.
  • Obfsproxy probably evades the DPI boxes too.

Type of firewall

  • Manufactorer: nothing definitive, possibly something from ZTE Corp. It is hard to narrow down the DPI boxes because traceroutes get dropped somewhere in the network backbone.

Reproducing the blocking

  • Binaries, patches etc can be found in censorship-timeline.git
  • Due to the firewall being stateless and in-band, it is easy to trigger and analyze blocking. The tool hping3 can be used to send data to an arbitrary machine in Ethiopia. If the machine answers with a RST segment, the data passed. If it does not answer, the data was probably dropped by the firewall:
  • A vanilla Tor (v0.2.2.37) TLS server hello can be used to trigger dropping:
  • Running Ethiopian machines for the test can be found by iterating over the address blocks announced by